這篇blog的問(wèn)題不能算是解決，僅僅只是一種分析和猜測(cè)，后續(xù)的一些行動(dòng)可能會(huì)證明一些猜想，也可能什么都解決不了。如果有和我相同情況的同學(xué)，也知道是什么問(wèn)題造成的，請(qǐng)不吝賜教。
問(wèn)題：
上周周末，沒(méi)有和同事們出去Outing，在家管孩子，去生產(chǎn)環(huán)境觀察了一下集群機(jī)器的當(dāng)前運(yùn)行狀態(tài)，發(fā)現(xiàn)應(yīng)用在這些多核機(jī)器上壓力極端不均勻。
Top一下大致?tīng)顟B(tài)如下：
峰值的時(shí)候，單CPU的使用率都到了80%，這種情況對(duì)于多核服務(wù)器來(lái)說(shuō)是很不正常的使用。對(duì)于Java的開(kāi)發(fā)者來(lái)說(shuō)，多線程編程是無(wú)法控制線程如何在CPU上分配的，因?yàn)?/span>Java本身不實(shí)現(xiàn)線程機(jī)制，說(shuō)是跨平臺(tái)的語(yǔ)言，但是性能及特性會(huì)根據(jù)操作系統(tǒng)的實(shí)現(xiàn)有很大的差異，因此Java調(diào)優(yōu)有時(shí)候需要對(duì)系統(tǒng)配置甚至內(nèi)核作調(diào)優(yōu)。
分析：
首先在測(cè)試環(huán)境下作了多次同樣的壓力測(cè)試，嘗試了與線上一樣的操作系統(tǒng)版本，相似的配置，但測(cè)試結(jié)果卻是負(fù)載分配很均勻。
此時(shí)重新啟動(dòng)了一臺(tái)問(wèn)題機(jī)器，發(fā)現(xiàn)負(fù)載降下來(lái)了，同時(shí)也很均衡，也就是說(shuō)在當(dāng)前的壓力下不應(yīng)該有這樣高的cpu消耗，同時(shí)也排除了硬件或者操作系統(tǒng)的一些配置問(wèn)題。
在CPU滿負(fù)荷的情況下，很多時(shí)候會(huì)認(rèn)為應(yīng)該是循環(huán)造成的，對(duì)于單個(gè)CPU的消耗更是。通過(guò)Top H查看具體到底哪一個(gè)線程會(huì)長(zhǎng)時(shí)間消耗CPU。
可以看到PID為13659的線程是“罪魁禍?zhǔn)?#8221;，但13659究竟在干什么，是應(yīng)用的線程還是系統(tǒng)的線程，是否是陷入了死循環(huán)，不得而知。接著就按照Java的土辦法，Kill -3 pid，然后看看輸出日志。
根據(jù)線程號(hào)來(lái)查找dump出來(lái)的日志中nid，發(fā)現(xiàn)這個(gè)線程是VM Thread，也就是虛擬機(jī)線程。（這里作一下轉(zhuǎn)換，將13659轉(zhuǎn)換成為16進(jìn)制就是0x355b）
用pstack看了一下這個(gè)線程的工作，結(jié)果如下：
Thread 2074 (Thread 1846541216 (LWP 13659)):
#0 0x0659fa65 in ObjectSynchronizer::deflate_idle_monitors ()
#1 0x065606e5 in SafepointSynchronize::begin ()
#2 0x06613e83 in VMThread::loop ()
#3 0x06613a6f in VMThread::run ()
#4 0x06506709 in java_start ()
#5 0x00aae3cc in start_thread () from /lib/tls/libpthread.so.0
#6 0x00a1896e in clone () from /lib/tls/libc.so.6
搜索了一下ObjectSynchronizer::deflate_idle_monitors，發(fā)現(xiàn)了sun的bug庫(kù)中有bug關(guān)于jdk1.6中由于這個(gè)方法導(dǎo)致運(yùn)行期問(wèn)題的說(shuō)法：http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=803cb2d95886bffffffff9a626d3b9b28573?bug_id=6781744
然后就直接去openjdk官方網(wǎng)站去查找這個(gè)類(lèi)的代碼，大致了解一下他的作用，具體的代碼鏈接如下：http://xref.jsecurity.net/openjdk-6/langtools/db/d8b/synchronizer_8cpp-source.html
主要工作應(yīng)該是對(duì)資源對(duì)象的回收，在加上pstack的結(jié)果，應(yīng)該大致知道是對(duì)線程資源的管理。但具體代碼就沒(méi)有進(jìn)一步分析了。
接著就分析一下自己的應(yīng)用：
壓力測(cè)試（高強(qiáng)度、長(zhǎng)時(shí)間）都做過(guò)，沒(méi)有發(fā)現(xiàn)什么異常。
本身應(yīng)用是否會(huì)存在的缺陷導(dǎo)致問(wèn)題呢。有人說(shuō)VM Thread兼顧著GC的工作，因此內(nèi)存泄露，對(duì)象長(zhǎng)期積壓過(guò)多也可能影響，但其實(shí)在dump的結(jié)果可以看到，GC有單獨(dú)的工作線程，同時(shí)我也觀察到GC這些線程的工作時(shí)間長(zhǎng)度，因此由于GC繁忙導(dǎo)致CPU上去，基本上來(lái)說(shuō)可以排除。
其次在SIP項(xiàng)目中使用了JDK的線程池(ExecutorService)和LinkedBlockingQueue。后者以前的文章里面提到在1.5版本里使用poll方法會(huì)有內(nèi)存泄露，到1.6雖然沒(méi)有內(nèi)存泄露，但是臨時(shí)鎖對(duì)象增長(zhǎng)的很快，會(huì)導(dǎo)致GC的頻度增加。
行動(dòng)：
上面零零散散的一些分析，最終讓我決定有如下的行動(dòng)：
1. 升級(jí)某一臺(tái)服務(wù)器的JDK，當(dāng)前是1.6.0_10-b33，打算升級(jí)到1.6的14版本。比較觀察多臺(tái)機(jī)器的表現(xiàn)，看是否升級(jí)了JDK可以解決問(wèn)題。
2. 去除LinkedBlockingQueue作為消息隊(duì)列，直接由生產(chǎn)者將生產(chǎn)結(jié)果按照算法分配給消費(fèi)者線程，避免競(jìng)爭(zhēng)，鎖的消耗，同時(shí)也防止LinkedBlockingQueue帶來(lái)的資源消耗。
3. 測(cè)試環(huán)境繼續(xù)作長(zhǎng)時(shí)間的壓力測(cè)試，同時(shí)可以結(jié)合Jprofile之類(lèi)的工具來(lái)分析長(zhǎng)時(shí)間后可能出現(xiàn)的問(wèn)題。
后話：
這年頭真的啥都要學(xué)一點(diǎn)，求人不如求己。
SA,DBA,測(cè)試都需要能夠去學(xué)習(xí)一些，起碼在初期排查問(wèn)題上自己能夠做點(diǎn)啥，要不然別人也忙，自己又無(wú)從下手。就好比這次壓力測(cè)試好不容易排上隊(duì)，但是還是滿足不了及時(shí)上線的需求，因此自己去LoadRunner壓，好歹給出一個(gè)零時(shí)的報(bào)告先大家看著。應(yīng)用的異常有時(shí)候是應(yīng)用本身設(shè)計(jì)問(wèn)題，也可能是開(kāi)發(fā)語(yǔ)言的問(wèn)題，也可能是操作系統(tǒng)的問(wèn)題，因此要去定位這種比較復(fù)雜的問(wèn)題，真的需要有耐心去好好的學(xué)習(xí)各種知識(shí)，現(xiàn)在看來(lái)知識(shí)還是匱乏啊，要不然就可以分析出openjdk中可能存在的問(wèn)題。