『壹』 2016 java緩存技術有哪些啊
（1100） （0）
一、什麼是緩存
1、Cache是高速緩沖存儲器 一種特殊的存儲器子系統，其中復制了頻繁使用的數據以利於快速訪問
2、凡是位於速度相差較大的兩種硬體/軟體之間的，用於協調兩者數據傳輸速度差異的結構，均可稱之為 Cache
二、緩存的分類
1、基於web應用的系統架構圖
2、在系統架構的不同層級之間，為了加快訪問速度，都可以存在緩存
操作系統磁碟緩存->減少磁碟機械操作
資料庫緩存->減少文件系統I/O
應用程序緩存->減少對資料庫的查詢
Web伺服器緩存->減少應用伺服器請求
客戶端瀏覽器緩存->減少對網站的訪問
三、操作系統緩存
1、文件系統提供的Disk Cache：操作系統會把經常訪問到的文件內容放入到內存當中，由文件系統來管理
2、當應用程序通過文件系統訪問磁碟文件的時候，操作系統從Disk Cache當中讀取文件內容，加速了文件讀取速度
3、Disk Cache由操作系統來自動管理，一般不用人工干預，但應當保證物理內存充足，以便於操作系統可以使用盡量多的內存充當Disk Cache，加速文件讀取速度
4、特殊的應用程序對文件系統Disk Cache有很高的要求，會繞開文件系統Disk Cache，直接訪問磁碟分區，自己實現Disk
5、Cache策略
Oracle的raw device(裸設備) – 直接拋棄文件系統
MySQL的InnoDB： innodb_flush_method = O_DIRECT
四、資料庫緩存
1、重要性
資料庫通常是企業應用系統最核心的部分
資料庫保存的數據量通常非常龐大
資料庫查詢操作通常很頻繁，有時還很復雜
以上原因造成資料庫查詢會引起非常頻繁的磁碟I/O讀取操作，迫使CPU掛起等待，資料庫性能極度低下
2、緩存策略
a、Query Cache
以SQL作為key值緩存查詢結果集
一旦查詢涉及的表記錄被修改，緩存就會被自動刪除
設置合適的Query Cache會極大提高資料庫性能
Query Cache並非越大越好，過大的Qquery Cache會浪費內存。
MySQL: query_cache_size= 128M
b、Data Buffer
data buffer是資料庫數據在內存中的容器
data buffer的命中率直接決定了資料庫的性能
data buffer越大越好，多多益善
MySQL的InnoDB buffer：innodb_buffer_pool_size = 2G
MySQL建議buffer pool開大到伺服器物理內存60-80%
五、應用程序緩存
1、對象緩存
由O/R Mapping框架例如Hibernate提供，透明性訪問，細顆粒度緩存資料庫查詢結果，無需業務代碼顯式編程，是最省事的緩存策略
當軟體結構按照O/R Mapping框架的要求進行針對性設計，使用對象緩存將會極大降低Web系統對於資料庫的訪問請求
良好的設計資料庫結構和利用對象緩存，能夠提供極高的性能，對象緩存適合OLTP（聯機事務處理）應用
2、查詢緩存
對資料庫查詢結果集進行緩存，類似資料庫的Query Cache
適用於一些耗時，但是時效性要求比較低的場景。查詢緩存和對象緩存適用的場景不一樣，是互為補充的
當查詢結果集涉及的表記錄被修改以後，需要注意清理緩存
3、頁面緩存
a、作用
針對頁面的緩存技術不但可以減輕資料庫伺服器壓力，還可以減輕應用伺服器壓力
好的頁面緩存可以極大提高頁面渲染速度
頁面緩存的難點在於如何清理過期的緩存
b、分類
I、動態頁面靜態化
利用模板技術將訪問過一次的動態頁面生成靜態html，同時修改頁面鏈接，下一次請求直接訪問靜態鏈接頁面
動態頁面靜態化技術的廣泛應用於互聯網CMS/新聞類Web應用，但也有BBS應用使用該技術，例如Discuz!
無法進行許可權驗證，無法顯示個性化信息
可以使用AJAX請求彌補動態頁面靜態化的某些缺點
II、Servlet緩存
針對URL訪問返回的頁面結果進行緩存，適用於粗粒度的頁面緩存，例如新聞發布
可以進行許可權的檢查
OScache提供了簡單的Servlet緩存(通過web.xml中的配置)
也可以自己編程實現Servlet緩存
III、頁面內部緩存
針對動態頁面的局部片斷內容進行緩存，適用於一些個性化但不經常更新的頁面(例如博客)
OSCache提供了簡單的頁面緩存
可以自行擴展JSP Tag實現頁面局部緩存
六、web伺服器端緩存
基於代理伺服器模式的Web伺服器端緩存，如squid/nginx
Web伺服器緩存技術被用來實現CDN（內容分發網路 content delivery network）
被國內主流門戶網站大量採用
不需要編程，但僅限於新聞發布類網站，頁面實時性要求不高
七、基於ajax的瀏覽器緩存
使用AJAX調用的時候，將資料庫在瀏覽器端緩存
只要不離開當前頁面，不刷新當前頁面，就可以直接讀取緩存數據
只適用於使用AJAX技術的頁面
『貳』 一級緩存的命中率是什麼
一般來說，每級緩存的命中率大概都在80%左右，全部數據量的80%都可以在
一級緩存
中找到，只剩下20%的總數據量才需要從二級緩存、三級緩存或內存中讀取.
讀取數據的成功率~
『叄』 nginx 緩存配置,對後端java服務有性能提升嗎
這個要看實際情況，涉及緩存命中率，如果後端全部都是動態數據，那麼根本無法緩存，所以沒有任何提升
『肆』 關於緩存命中率的計算
命中的話，讀寫時間為3ns，不命中，讀寫時間就是33ns，假設命中率是p，
則 3 x p + 33 x (1 - p) = 3.27，可以求出 p = 99.1%
『伍』 什麼是緩存的命中率
緩存具有比內存更快的運行速度，如果把所有可能用到的指令都放進緩存，那處理速度就會大大提高，那命中率就是100％了，可是這樣就需要很大的緩存，這樣性價比就會下降而且無此必要，所以緩存中只是存儲最可能用到的一些指令，根所需要的所有指令的比率就是命中率！
『陸』 我想問下緩存的命中率是什麼意思求答案
命中率=從緩存中讀取數據的次數/所有訪問數據次數(磁碟讀取次數+緩存讀取次數)
命中率定義理解為：
命中率＝命中數/(命中數＋沒有命中數)
終端用戶訪問伺服器時，如果該伺服器有緩存住了要被訪問的數據時就叫做命中，如果沒有的話需要回原伺服器取，就是沒有命中。取數據的過程與用戶訪問是同步進行的，所以即使是重新取的新數據，用戶也不會感覺到有延時
當客戶機訪問相同的游戲數據時，這時候游戲緩存才起到作用，一般緩存會把最近訪問比較多的游戲資源加到緩存中去，網吧客戶機訪問的游戲數據如果都是同一個游戲這時候命中率才會越高要達到100%是理想情況下，一般能達到70%-90%都算不錯了。
『柒』 什麼叫緩存命中率
其中很多人談到了緩存命中率的問題，應用緩存的命中率取決於很多的因素：
1、應用場景
是OLTP還是OLAP應用，即使是OLTP，也要看訪問的頻度，一個極少被訪問到的緩存等於沒有什麼效果。一般來說，互聯網網站是非常適合緩存應用的場景。
2、緩存的粒度
毫無疑問，緩存的粒度越小，命中率就越高，對象緩存是目前緩存粒度最小的，因此被命中的幾率更高。舉個例子來說吧：你訪問當前這個頁面，瀏覽帖子，那麼對於ORM來說，需要發送n條SQL，取各自帖子user的對象。很顯然，如果這個user在其他帖子裡面也跟貼了，那麼在訪問那個帖子的時候，就可以直接從緩存裡面取這個user對象了。
3、架構的設計
架構的設計對於緩存命中率也有至關重要的影響。例如你應該如何去盡量避免緩存失效的問題，如何盡量提供頻繁訪問數據的緩存問題，這些都是考驗架構師水平的地方。再舉個例子來說，對於論壇，需要記錄每個topic的瀏覽次數，所以每次有人訪問這個topic，那麼topic表就要update一次，這意味著什麼呢？對於topic的對象緩存是無效的，每次訪問都要更新緩存。那麼可以想一些辦法，例如增加一個中間變數記錄點擊次數，每累計一定的點擊，才更新一次資料庫，從而減低緩存失效的頻率。
4、緩存的容量和緩存的有效期
緩存太小，造成頻繁的LRU，也會降低命中率，緩存的有效期太短也會造成緩存命中率下降。
所以緩存命中率問題不能一概而論，一定說命中率很低或者命中率很高。但是如果你對於緩存的掌握很精通，有意識的去調整應用的架構，去分解緩存的粒度，總是會帶來很高的命中率的。
這里我可以舉一個實際的案例，JavaEye2.0網站在使用對象緩存之前，通過MySQL的監控工具進行觀察，在連續24小時的平均每秒發送SQL條數超過了200條，在使用對象緩存之後，連續24小時的平均每秒發送SQL條數下降到了120條左右，幾乎下降了一半。
考慮到很多SQL都是分頁語句，關聯查詢，條件查詢，集合操作，都是不能被緩存的SQL，而真正能夠被緩存的SQL只有根據主鍵查詢對象和對象關聯對象的查詢。所以真正能夠被緩存的SQL估計最多佔所有SQL的60%。所以換算下來，應用緩存的命中率之高，已經相當驚人了。
不過這里要提醒的一點，有將近一半的SQL都被緩存，不意味著性能可以提升一倍。這是因為能夠被緩存的都是按照主鍵查詢單條記錄的SQL，這些SQL本身即使發送到資料庫，對資料庫造成的壓力也沒有想像的那麼大。真正對資料庫造成龐大壓力的正是那些沒有索引的大表查詢，和造成了全表掃描的關聯查詢，這些一旦涉及到全表掃描的查詢，才是性能的真正殺手。當然了，不管怎麼說，通過使用對象緩存，是毫無疑問可以大幅度降低資料庫的負載壓力的，有效提升web應用的性能的。
關於這一點，我再給出一組數據來加深大家的印象，通過使用操作系統網路工具進行統計：
JavaEye網站web server的埠每秒數據流量是2MB；
JavaEye網站的MySQL資料庫埠的每秒數據流量是1.2MB；
而網站的memcached的埠每秒的數據流量高達5MB
『捌』 緩存命中率的影響因素
緩存的命中率取決於很多的因素： 緩存太小，造成頻繁的LRU，也會降低命中率，緩存的有效期太短也會造成緩存命中率下降。
所以緩存命中率問題不能一概而論，一定說命中率很低或者命中率很高。但是如果你對於緩存的掌握很精通，有意識的去調整應用的架構，去分解緩存的粒度，總是會帶來很高的命中率的。
『玖』 java內存或者是緩存管理怎麼實現
我不太清楚你為什麼用map來存放數據？你用什麼作為key呢？如果是我做的話我會自定義一個對象，裡面大體上有如下屬性：發言人、發言時間、發言內容等。然後用list存放這些對象，list是由順序的。如果長度到達一定值可以把最先放進去的對象清除掉或移動到其他地方。
『拾』 Java和C++有什麼區別對於軟體的性能優化哪個好
C++ 在大部分的情況下都比 Java 要快，有幾個數值方面的基準測試的研究爭辯說 Java 在某些情況下可能會比 C++ 的性能好得多。但有人說數值方面的基準測試對於語言的評估是不合適的，因為編譯器都可以做相關的優化，甚至可能將被測試的代碼徹底刪除。 如果涉及到一個真正現實應用的程序，Java 會因為很多原因導致性能變差：
所有的對象都在堆里被申請。對於使用小對象的函數來說會導致很大的性能損失，因為在棧里申請內存幾乎沒有性能損失。
方法預設是虛的。這對於小對象來說會因為虛表增加好幾倍的內存使用。它也會引起性能損失，因為 JIT 編譯器不得不對查虛表的過程做額外的優化。
即使使用標準的容器依然會有很多的類型轉換，這會引起性能損失，因為需要遍歷整個繼承樹。
虛擬機更進一步增加了內存的使用，因此降低了內存的局部性，增加了緩存命中失敗率，從而導致整個程序變慢。
缺乏低級細節的操作方式使得開發者無法將程序進一步優化，因為編譯器不支持。
有人爭論說，和 Java 相比 C++也有很多劣勢：
指針使得優化變得困難，因為它們可能指向任意的數據。當然現在這一點也並非完全正確，因為一些現代的編譯器引入了 "嚴格別名" 的規則 並且支持 C99 的關鍵字 restrict，從而嚴格限制了指針的使用，使其只能用於指向已知的變數
Java 的垃圾搜集和使用malloc/new來申請內存相比能擁有更好的緩存連貫性，因為它的申請一般來說是順序的。然而，始終有爭論認為二者同樣會導致內存的「零碎化」（即多次分配和回收之後內存空間會變得不連續），且並沒有哪一個比對方有更明顯的緩存優勢。
運行時編譯可能可以更好的優化代碼，因為可以利用運行時的額外的信息，例如知道代碼是在什麼樣的處理器上運行。然而當今的情況也並非完全如此，因為當前最先進的 C++ 編譯器也會針對不同系統生成不同的目標代碼，以期充分利用該系統的計算能力
此外，有爭議的是，花在更復雜的 C++ 代碼上的 debug 時間太多，用 Java 開發完全可以把這些時間用來優化 Java 代碼。當然對於一個給定的程序來說兩種語言能優化到什麼程度也是一方面。最後，對於處理器負擔很重的情況，例如視頻渲染，C++ 能直接訪問硬體，在同樣一個硬體規格下 C++ 總是會比 Java 的表現好很多。