常用的監(jiān)控指令
監(jiān)控線(xiàn)程上下文切換 pidstat -w -I -p 9391 5 解釋?zhuān)? pidstat -w每5秒監(jiān)控進(jìn)程id為9391的java應(yīng)用
下面估計(jì)上下文切換鎖浪費(fèi)的時(shí)鐘周期。處理器為3.0GHZ 雙核
pidstat -w 顯示系統(tǒng)每秒大約發(fā)生3500個(gè)上下文切換。每個(gè)虛擬處理器的上下文切換為3500/2-1750，耗費(fèi)的時(shí)鐘周期為1750*8000=140000000，3ghz cpu每秒的時(shí)鐘周期數(shù)為3000000000.因此上下文切換浪費(fèi)的時(shí)鐘周期為
14000000/3000000000=4.7%.再次應(yīng)用一般性準(zhǔn)則（即讓步時(shí)鐘周期占用3-5%或者更多的時(shí)鐘周期），說(shuō)明java引用正面鎖競(jìng)爭(zhēng)。P25
2.4.8監(jiān)控?fù)屨际缴舷挛那袚Q
主動(dòng)切換和 被動(dòng)切換
2.4.9 監(jiān)控線(xiàn)程遷移
待運(yùn)行線(xiàn)程在處理器之間的遷移也會(huì)導(dǎo)致性能下降。大多數(shù)操作系統(tǒng)的CPU調(diào)度程序會(huì)將代運(yùn)行線(xiàn)程分配給上次運(yùn)行它的虛擬處理器。遷移線(xiàn)程會(huì)造成性能影響是因?yàn)樾碌奶摂M處理器緩存中沒(méi)有代運(yùn)行線(xiàn)程所需的數(shù)據(jù)或狀態(tài)信息。減少遷移的策略是創(chuàng)建處理器組并將java應(yīng)用分配給這些處理器組。一般性的準(zhǔn)則是，如果橫跨多個(gè)核或虛擬處理器的java引用每秒遷移超過(guò)500次，將java應(yīng)用綁定在處理器組上就有好處。
2.5 網(wǎng)絡(luò)I/O使用率
2.5.2 Linux 監(jiān)控網(wǎng)絡(luò)I/O使用率
2.6磁盤(pán)I/O利用率
iostat -xm 5
第3章
JVM 概覽
hotspot VM運(yùn)行時(shí)：命令行選項(xiàng)解析、VM生命周期的管理、類(lèi)加載、字節(jié)碼解釋、異常處理、同步、線(xiàn)程管理、java本地接口、VM知名錯(cuò)誤處理和c++堆管理
啟動(dòng)步驟：p43
3.2.8 同步
HotSpot VM用monitor對(duì)象來(lái)保障線(xiàn)程運(yùn)行代碼之間的互斥。java的monitor對(duì)象可以鎖定或者解鎖，但任何時(shí)刻只能有一個(gè)線(xiàn)程擁有該monitor對(duì)象，只有獲得Monitor對(duì)象的所有權(quán)后，線(xiàn)程才可以進(jìn)入它鎖保護(hù)的臨界區(qū)，Java中臨界區(qū)由同步快（Synchronzed Block）表示
VM吸收了非競(jìng)爭(zhēng)和競(jìng)爭(zhēng)性同步操作的先進(jìn)技術(shù)，jdk1.5引入偏向鎖（命令行-XX：+UseBiasedLocking）、最好情況下成本甚至為零。既然大多數(shù)對(duì)象在其生命期中最多只會(huì)被一個(gè)線(xiàn)程鎖住，那就可以開(kāi)啟-XX：+UseBiasedLocking允許線(xiàn)程自身使用偏向鎖。一旦開(kāi)啟偏向鎖，該線(xiàn)程不需要借助昂貴的原子指令就可以對(duì)該對(duì)象進(jìn)行鎖定和解鎖了。
大多數(shù)HotSpot VM 同步操作使用稱(chēng)為fast-path代碼，hotspot VM 有兩個(gè)JIT編譯器和一個(gè)解釋器，它們都可以稱(chēng)為fast-path代碼，C1-----clientJIT編譯器和C2-------- -ServerJIT編譯器。 C1和C2在同步點(diǎn)時(shí)都可以直接生成fast-path代碼，沒(méi)有競(jìng)爭(zhēng)時(shí)，同步操作通常全部在fast-path代碼中完成。，然而需要阻塞或者喚醒線(xiàn)程（分別是monitor-enter 或者monitor-exit狀態(tài)），fast-path代碼將第阿勇slow-path代碼。slow-path代碼由c++實(shí)現(xiàn)，而-fast-path代碼則是JIT編譯器產(chǎn)生機(jī)器代碼。
HotSpot vm內(nèi)部表示java對(duì)象的第一個(gè)字（word），包括了java對(duì)象的同步狀態(tài)編碼，通常稱(chēng)為標(biāo)記字（mark word）為了節(jié)約空間，標(biāo)記字會(huì)根據(jù)不同的狀態(tài)，服用存儲(chǔ)空間，包含其他的同步元數(shù)據(jù)。
3.2.12 VM致命錯(cuò)誤處理
OutOfMemoryError
HotSpot VM 生成的錯(cuò)誤信息中包含了棧的最終信息,此外還引入了-XX:OnOutOfMemoryError=<cmd> 所以當(dāng)拋出第一個(gè)OutOfMemoryError時(shí)，可以執(zhí)行一條命令，另一個(gè)值得提及的有用的特性是，當(dāng)OutOfMemoryError出現(xiàn)時(shí)候可以生成堆的轉(zhuǎn)存信息。指定-XX:HeapDumpOnOutMemory可以開(kāi)啟的這個(gè)特性。另外一個(gè)HotSpot VM 命令行選項(xiàng) -XX:HeapDump- Path=<pathname>可讓用戶(hù)指定堆轉(zhuǎn)儲(chǔ)的存放路徑。
退出發(fā)送 SIGOUIT信號(hào)給java進(jìn)程id也可以得到同樣的效果。基于線(xiàn)程的棧追蹤信息，可以分析死鎖根源，自帶的JConsole工具添加了一項(xiàng)功能，可以聯(lián)系到一個(gè)掛起的java進(jìn)程并分析死鎖的根源。多數(shù)情況下，死鎖是由于獲取鎖的順序錯(cuò)誤鎖導(dǎo)致的
重要的HotSpot VM 選項(xiàng)
-client
-server
-d64 加載64位hotspot VM而不是默認(rèn)的32位hotspot VM
當(dāng)堆內(nèi)存需要32G以上的時(shí)候采用該選項(xiàng)，-Xmx -Xms 小于32G時(shí)，該選項(xiàng)要與-XX+UseCompressedOops聯(lián)合使用 jdk6 后默認(rèn)開(kāi)啟
java引用的長(zhǎng)度從32位增加到64位，這給64位JVM帶來(lái)了性能損失。長(zhǎng)度的增加使得緩存行中可容納的oops（普通對(duì)象指針）變少----因?yàn)?4地址長(zhǎng)度變大 直接導(dǎo)致實(shí)際數(shù)據(jù)存儲(chǔ)量的下降，CPU高速緩存的效率也降低。
-xms<n>[g|m|k] 默認(rèn)堆
-xmx<n>[g|m|k] 最大堆
-XX:NewSize=<n>[g|m|k]最小新生代
-XX:MaxNewSize=<n>[g|m|k]最大
-Xmn<n>[g|m|k]同時(shí)設(shè)置新生代的初始，最小和最大尺寸
-XX:NewRatio=<n>新生代和老年代的尺寸比例 n默認(rèn)為3 比例為1：3
-XX:PermSize=<n>[g|m|k]
-XX:MaxPermSize=<n>[g|m|k]
-XX:SurvivorRatio=n 單塊Survivor區(qū)和Eden區(qū)大小比例
。。。P416
