最近發現服務cpu消耗不是很穩定，在150%~600%之間不停跳動，以前沒有這種情況，check了一下，是old區記憶體不太夠導致每隔一小段時間cms gc了，old區記憶體不夠的主要原因是服務需要載入的資料變多了，使得old區頻繁gc；
用 jmap -heap $pid 可以看到當old區佔比超過92%時就會觸發cms，以前一直以為cms觸發是68%，查了下資料，
jdk5預設68%，jdk6預設92%；這個需要注意一下；當預設92%時，服務還會發生
promotion failed
，此時會消耗大量的時間用來full gc；
正確的做法是：
1.增大old區，從原先10g增大到13g，原年輕代2g保持不變，減少cms gc次數；
2.設定cmsinitiatingoccupancyfraction引數，基本滿足
(xmx-xmn)*(100- cmsinitiatingoccupancyfraction)/100>=xmn
即可（xmx為堆大小，xmn為年輕代大小），這樣能保證即使在cms gc時候old區也能接受來自於年輕代gc的物件，這樣就不會觸發promotion failed；簡單計算一下，cmsinitiatingoccupancyfraction<85就不會觸發了，個人暫時設定84，因為old區需要儲存一些索引類資料或者快取，設定太小容易頻繁cms gc；
good night.
JVM快取行對齊效能優化
快取是由多個快取行組成的，以快取行為基本單位，乙個快取行的大小一般為64位元組。因為快取行存在，當不同的執行緒在操作兩份不同的資料時，如果這兩份資料剛好位於同乙個快取行中，那麼彼此之間就會互相影響。所以為了解決偽共享的問題，就出現了快取行對齊的方式，也就是讓c d兩份資料分別獨佔乙個快取行，這樣就不...
jvm引數優化
堆記憶體優化 調整jvm啟動引數 xms xmx xx newsize xx maxnewsize，如調整初始堆記憶體和最大對記憶體 xms256m xmx512m。或者調整初始new generation的初始記憶體和最大記憶體 xx newsize 128m xx maxnewsize 128m...
jvm晚期優化
最具代表性的幾個優化技術 公共子表示式消除描述 如果乙個表示式e已經計算過了，並且從先前的計算到現在e中的所有變數的值都沒有發生變化，那麼e的這次出現就成為了公共子表示式 int d c b 12 a a b c 優化為int d e 12 a a e 優化為int d e 13 a 2陣列泛微檢查...