jvm gc 調優 實戰

時間  2019-11-29
標籤 jvm 實戰 欄目 Java 简体版
原文   原文鏈接

很是不錯的文章們 轉自：html

中文：http://blog.csdn.net/dragonassassin/article/details/51010947java

http://josh-persistence.iteye.com/blog/2161848?utm_source=tuicool&utm_medium=referrallinux

英文：超級超級超級無敵棒的Gc問題調優五部曲程序員

https://www.cubrid.org/blog/understanding-java-garbage-collection算法

https://www.cubrid.org/blog/how-to-monitor-java-garbage-collection/spring

https://www.cubrid.org/blog/how-to-tune-java-garbage-collectionapache

https://www.cubrid.org/blog/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc數組

https://www.cubrid.org/blog/the-principles-of-java-application-performance-tuning瀏覽器

前提概要： sass

       JDK自己提供了不少方便的JVM性能調優監控工具，除了集成式的VisualVM和jConsole外，還有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一種工具都有其自身的特色，用戶能夠根據你須要檢測的應用或者程序片斷的情況，適當的選擇相應的工具進行檢測。接下來的兩個專題分別會講VisualVM的具體應用。

 

現實企業級Java開發中，有時候咱們會碰到下面這些問題：

  • OutOfMemoryError，內存不足

  • 內存泄露

  • 線程死鎖

  • 鎖爭用（Lock Contention）

  • Java進程消耗CPU太高

  • ......

這些問題在平常開發中可能被不少人忽視（好比有的人遇到上面的問題只是重啓服務器或者調大內存，而不會深究問題根源），但可以理解並解決這些問題是Java程序員進階的必備要求。

 

 

1、 jps(Java Virtual Machine Process Status Tool)      ： 基礎工具

       實際中這是最經常使用的命令，下面要介紹的小工具更多的都是先要使用jps查看出當前有哪些Java進程，獲取該Java進程的id後再對該進程進行處理。

 

    jps主要用來輸出JVM中運行的進程狀態信息。語法格式以下：

 

Java代碼   收藏代碼
  1. jps [options] [hostid]  

 若是不指定hostid就默認爲當前主機或服務器。

 

  命令行參數選項說明以下：

 

Java代碼   收藏代碼
  1. -q 不輸出類名、Jar名和傳入main方法的參數  
  2. -m 輸出傳入main方法的參數  
  3. -l 輸出main類或Jar的全限名  
  4. -v 輸出傳入JVM的參數  

 

  

好比

一、我如今有一個WordCountTopo的Strom程序正在本機運行。

二、使用java -jar deadlock.jar & 啓動一個線程死鎖的程序 

 

 

Java代碼   收藏代碼
  1. wangsheng@WANGSHENG-PC /E  
  2. $ jps -ml  
  3. 14200 deadlock.jar  
  4. 13952 com.wsheng.storm.topology.WordCountTopo D://input/ 3  
  5. 13248 sun.tools.jps.Jps -ml  
  6. 9728  

  

2、 jstack    jstack主要用來查看某個Java進程內的線程堆棧信息。語法格式以下：

 

Java代碼   收藏代碼
  1. jstack [option] pid  
  2. jstack [option] executable core  
  3. jstack [option] [server-id@]remote-hostname-or-ip  

 

Java代碼   收藏代碼
  1. 命令行參數選項說明以下：  

 

Java代碼   收藏代碼
  1. -l long listings，會打印出額外的鎖信息，在發生死鎖時能夠用<strong>jstack -l pid</strong>來觀察鎖持有狀況  
  2. -m mixed mode，不只會輸出Java堆棧信息，還會輸出C/C++堆棧信息（好比Native方法）  

 

    jstack能夠定位到線程堆棧，根據堆棧信息咱們能夠定位到具體代碼，因此它在JVM性能調優中使用得很是多。

    下面咱們來一個實例：

     找出某個Java進程中最耗費CPU的Java線程並定位堆棧信息，用到的命令有ps、top、printf、jstack、grep。

   

    第一步： 先找出Java進程ID，服務器上的Java應用名稱爲wordcount.jar：

  

Java代碼   收藏代碼
  1. [root@storm-master home]# ps -ef | grep wordcount | grep -v grep  
  2. root       2860   2547 13 02:09 pts/0    00:02:03 java -jar wordcount.jar /home/input 3  

 

    獲得進程ID爲2860,

 

    第二步:找出該進程內最耗費CPU的線程，可使用以下3個命令，這裏咱們使用第3個命令得出以下結果：

Java代碼   收藏代碼
  1. 1）ps -Lfp pid ： 即 ps -Lfp 2860  
  2. 2）ps -mp pid -o THREAD, tid, time ：即 ps -mp 2860 -o THREAD,tid,time  
  3. 3）top -Hp pid： 即 <strong>top -Hp 2860</strong>  
  4. 用第三個，輸出以下：   

 

 

  TIME列就是各個Java線程耗費的CPU時間，顯然CPU時間最長的是ID爲2968的線程，用

 

Java代碼   收藏代碼
  1. printf "%x\n" 2968  

    獲得2968的十六進制值爲b98，下面會用到。     

 

    第三步：終於輪到jstack上場了，它用來輸出進程2860的堆棧信息，而後根據線程ID的十六進制值grep，以下：

 

Java代碼   收藏代碼
  1. [root@storm-master home]# jstack 2860 | grep b98  
  2. "SessionTracker" prio=10 tid=0x00007f55a44e4800 nid=0xb53 in Object.wait() [0x00007f558e06c000  

 

 能夠看到CPU消耗在SessionTracker這個類的Object.wait()，因而就能很容易的定位到相關的代碼了。

 

  

3、 jmap（Memory Map）和 jhat（Java Heap Analysis Tool）：

jmap導出堆內存，而後使用jhat來進行分析

 

    jmap用來查看堆內存使用情況，通常結合jhat使用。

 

    jmap語法格式以下：

 

Java代碼   收藏代碼
  1. jmap [option] pid  
  2. jmap [option] executable core  
  3. jmap [option] [server-id@]remote-hostname-or-ip  

 若是運行在64位JVM上，因爲linux操做系統的不一樣，可能須要指定-J-d64命令選項參數。

 

 

 一、打印進程的類加載器和類加載器加載的持久代對象信息： jmap -permstat pid

我的感受這個不是太有用蠢話

 

輸出：類加載器名稱、對象是否存活（不可靠）、對象地址、父類加載器、已加載的類大小等信息，如圖：

 


 

 

二、查看進程堆內存使用狀況:包括使用的GC算法、堆配置參數和各代中堆內存使用：jmap -heap pid

 

好比下面的例子

 

Java代碼   收藏代碼
  1. [root@storm-master home]# jmap -heap 2860  
  2. Attaching to process ID 2860, please wait...  
  3. Debugger attached successfully.  
  4. Server compiler detected.  
  5. JVM version is 20.45-b01  
  6.   
  7. using thread-local object allocation.  
  8. Mark Sweep Compact GC  
  9.   
  10. Heap Configuration:  
  11.    MinHeapFreeRatio = 40  
  12.    MaxHeapFreeRatio = 70  
  13.    MaxHeapSize      = 257949696 (246.0MB)  
  14.    NewSize          = 1310720 (1.25MB)  
  15.    MaxNewSize       = 17592186044415 MB  
  16.    OldSize          = 5439488 (5.1875MB)  
  17.    NewRatio         = 2  
  18.    SurvivorRatio    = 8  
  19.    PermSize         = 21757952 (20.75MB)  
  20.    MaxPermSize      = 85983232 (82.0MB)  
  21.   
  22. Heap Usage:  
  23. New Generation (Eden + 1 Survivor Space):  
  24.    capacity = 12189696 (11.625MB)  
  25.    used     = 6769392 (6.4557952880859375MB)  
  26.    free     = 5420304 (5.1692047119140625MB)  
  27.    55.53372290826613% used  
  28. Eden Space:  
  29.    capacity = 10878976 (10.375MB)  
  30.    used     = 6585608 (6.280525207519531MB)  
  31.    free     = 4293368 (4.094474792480469MB)  
  32.    60.53518272307982% used  
  33. From Space:  
  34.    capacity = 1310720 (1.25MB)  
  35.    used     = 183784 (0.17527008056640625MB)  
  36.    free     = 1126936 (1.0747299194335938MB)  
  37.    14.0216064453125% used  
  38. To Space:  
  39.    capacity = 1310720 (1.25MB)  
  40.    used     = 0 (0.0MB)  
  41.    free     = 1310720 (1.25MB)  
  42.    0.0% used  
  43. tenured generation:  
  44.    capacity = 26619904 (25.38671875MB)  
  45.    used     = 15785896 (15.054603576660156MB)  
  46.    free     = 10834008 (10.332115173339844MB)  
  47.    59.30110040967841% used  
  48. Perm Generation:  
  49.    capacity = 33554432 (32.0MB)  
  50.    used     = 33323352 (31.779624938964844MB)  
  51.    free     = 231080 (0.22037506103515625MB)  
  52.    99.31132793426514% used  

 

 三、查看堆內存中的對象數目、大小統計直方圖，若是帶上live則只統計活對象：jmap -histo[:live] pid

 

 

Java代碼   收藏代碼
  1. [root@storm-master Desktop]# jmap -histo 2860  
  2.   
  3.  num     #instances         #bytes  class name  
  4. ----------------------------------------------  
  5.    1:         13917       11432488  [B  
  6.    2:          6117        6181448  <instanceKlassKlass>  
  7.    3:         39520        6004504  <constMethodKlass>  
  8.    4:          6117        5517072  <constantPoolKlass>  
  9.    5:         39520        5383280  <methodKlass>  
  10.    6:          5148        3150944  <constantPoolCacheKlass>  
  11.    7:         29954        2810640  [C  
  12.    8:         50179        2469272  <symbolKlass>  
  13.    9:         42122        1791704  [Ljava.lang.Object;  
  14.   10:          1804         961464  <methodDataKlass>  
  15.   11:         11747         941200  [Ljava.util.HashMap$Entry;  
  16.   12:         28786         921152  java.lang.String  
  17.   13:          6347         660088  java.lang.Class  
  18.   14:          7374         625616  [S  
  19.   15:         11740         563520  java.util.HashMap  
  20.   16:         23447         562728  clojure.lang.PersistentHashMap$BitmapIndexedNode  
  21.   17:         10980         351360  clojure.lang.Symbol  
  22.   18:          8544         341760  java.lang.ref.SoftReference  
  23.   19:          8028         336632  [[I  
  24.   20:          3944         283968  java.lang.reflect.Constructor  
  25.   21:          4744         227712  java.nio.HeapByteBuffer  
  26.   22:          6854         219328  java.util.AbstractList$Itr  
  27.   23:          2185         195192  [I  
  28.   24:          3854         184992  java.nio.HeapCharBuffer  
  29.   25:          5500         176000  java.util.concurrent.ConcurrentHashMap$HashEntry  

 

 class name是對象類型，說明以下: 

 

Java代碼   收藏代碼
  1. B  byte  
  2. C  char  
  3. D  double  
  4. F  float  
  5. I  int  
  6. J  long  
  7. Z  boolean  
  8. [  數組，如[I表示int[]  
  9. [L+類名 其餘對象  

 

    四、還有一個很經常使用的狀況是：用jmap把進程內存使用狀況dump到文件中，再用jhat分析查看。須要注意的是 dump出來的文件還能夠用MAT、VisualVM等工具查看。

jmap進行dump命令格式以下：

 

Java代碼   收藏代碼
  1. <strong>jmap -dump:format=b,file=dumpFileName pid</strong>  

 

    我同樣地對上面進程ID爲2860進行Dump：

  

Java代碼   收藏代碼
  1. [root@storm-master Desktop]# jmap -dump:format=b,file=/home/dump.dat 2860  
  2. Dumping heap to /home/dump.dat ...  
  3. Heap dump file created  

 

  而後使用jhat來對上面dump出來的內容進行分析 

 

Java代碼   收藏代碼
  1. [root@storm-master Desktop]# jhat -port 8888 /home/dump.dat   
  2. Reading from /home/dump.dat...  
  3. Dump file created Sat Aug 01 04:21:12 PDT 2015  
  4. Snapshot read, resolving...  
  5. Resolving 411123 objects...  
  6. Chasing references, expect 82 dots..................................................................................  
  7. Eliminating duplicate references..................................................................................  
  8. Snapshot resolved.  
  9. Started HTTP server on port 8888  
  10. Server is ready.  

 

    注意若是Dump文件太大，可能須要加上-J-Xmx512m參數以指定最大堆內存，即jhat -J-Xmx512m -port 8888 /home/dump.dat。而後就能夠在瀏覽器中輸入主機地址:8888查看了：

 

 

點擊每個藍色的超連接，你都會看到其相關更具體的信息，而最後一項更是支持OQL（對象查詢語言）。

 

4、jstat（JVM統計監測工具）: 看看各個區內存和GC的狀況

 

    語法格式以下：

 

Java代碼   收藏代碼
  1. jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]  

 vmid是Java虛擬機ID，在Linux/Unix系統上通常就是進程ID。interval是採樣時間間隔。count是採樣數目。好比下面輸出的是GC信息，採樣時間間隔爲250ms，採樣數爲6：

 

Java代碼   收藏代碼
  1. [root@storm-master Desktop]# jstat -gc 2860 250 6  

 

 

 

要明白上面各列的意義，先看JVM堆內存佈局：

 

能夠看出：

Java代碼   收藏代碼
  1. 堆內存 = 年輕代 + 年老代 + 永久代  
  2. 年輕代 = Eden區 + 兩個Survivor區（From和To）  

 如今來解釋各列含義：

Java代碼   收藏代碼
  1. S0C、S1C、S0U、S1U：Survivor 0/1區容量（Capacity）和使用量（Used）  
  2. EC、EU：Eden區容量和使用量  
  3. OC、OU：年老代容量和使用量  
  4. PC、PU：永久代容量和使用量  
  5. YGC、YGT：年輕代GC次數和GC耗時  
  6. FGC、FGCT：Full GC次數和Full GC耗時  
  7. GCT：GC總耗時  

 

5、hprof（Heap/CPU Profiling Tool）：    hprof可以展示CPU使用率，統計堆內存使用狀況。

      HPROF: 一個Heap/CPU Profiling工具：J2SE中提供了一個簡單的命令行工具來對java程序的cpu和heap進行 profiling，叫作HPROF。HPROF其實是JVM中的一個native的庫，它會在JVM啓動的時候經過命令行參數來動態加載，併成爲 JVM進程的一部分。若要在java進程啓動的時候使用HPROF，用戶能夠經過各類命令行參數類型來使用HPROF對java進程的heap或者 （和）cpu進行profiling的功能。HPROF產生的profiling數據能夠是二進制的，也能夠是文本格式的。這些日誌能夠用來跟蹤和分析 java進程的性能問題和瓶頸，解決內存使用上不優的地方或者程序實現上的不優之處。二進制格式的日誌還能夠被JVM中的HAT工具來進行瀏覽和分析，用 以觀察java進程的heap中各類類型和數據的狀況。在J2SE 5.0之後的版本中，HPROF已經被併入到一個叫作Java Virtual Machine Tool Interface（JVM TI）中。

   

語法格式以下：

Java代碼   收藏代碼
  1. java -agentlib:hprof[=options] ToBeProfiledClass  
  2. java -Xrunprof[:options] ToBeProfiledClass  
  3. javac -J-agentlib:hprof[=options] ToBeProfiledClass  

 完整的命令選項以下：

Java代碼   收藏代碼
  1. Option Name and Value  Description                    Default  
  2. ---------------------  -----------                    -------  
  3. heap=dump|sites|all    heap profiling                 all  
  4. cpu=samples|times|old  CPU usage                      off  
  5. monitor=y|n            monitor contention             n  
  6. format=a|b             text(txt) or binary output     a  
  7. file=<file>            write data to file             java.hprof[.txt]  
  8. net=<host>:<port>      send data over a socket        off  
  9. depth=<size>           stack trace depth              4  
  10. interval=<ms>          sample interval in ms          10  
  11. cutoff=<value>         output cutoff point            0.0001  
  12. lineno=y|n             line number in traces?         y  
  13. thread=y|n             thread in traces?              n  
  14. doe=y|n                dump on exit?                  y  
  15. msa=y|n                Solaris micro state accounting n  
  16. force=y|n              force output to <file>         y  
  17. verbose=y|n            print messages about dumps     y  

 

- Get sample cpu information every 20 millisec, with a stack depth of 3: 

         java -agentlib:hprof=cpu=samples,interval=20,depth=3 classname 
     - Get heap usage information based on the allocation sites: 
         java -agentlib:hprof=heap=sites classname 

      上面每隔20毫秒採樣CPU消耗信息，堆棧深度爲3，生成的profile文件名稱是java.hprof.txt，在當前目錄。 

      默認狀況下，java進程profiling的信息（sites和dump）都會被 寫入到一個叫作java.hprof.txt的文件中。大多數狀況下，該文件中都會對每一個trace，threads，objects包含一個ID，每一 個ID表明一個不一樣的觀察對象。一般，traces會從300000開始。 默認，force=y，會將全部的信息所有輸出到output文件中，因此若是含有 多個JVMs都採用的HRPOF enable的方式運行，最好將force=n，這樣可以將單獨的JVM的profiling信息輸出到不一樣的指定文件。 interval選項只在 cpu=samples的狀況下生效，表示每隔多少毫秒對java進程的cpu使用狀況進行一次採集。 msa選項僅僅在Solaris系統下才有效， 表示會使用Solaris下的Micro State Accounting功能 

 

  

第二部分： 實例部分：

該部分將使用相關的實例和前面提到的JVM性能調優工具來進行性能診斷。

 

一、使用jstack來分析死鎖問題：

       上面說明中提到 jstack主要用來查看某個Java進程內的線程堆棧信息,您可使用它查明問題。jstack [-l] <pid>,pid能夠經過使用jps命令來查看當前Java程序的pid值,-l是可選參數,它能夠顯示線程阻塞/死鎖狀況

 

Java代碼   收藏代碼
  1. package com.wsheng.aggregator.thread.performance;  
  2.   
  3. import org.springframework.stereotype.Component;  
  4.   
  5. /** 
  6.  * Dead lock example 
  7.  *  
  8.  * @author Josh Wang(Sheng) 
  9.  * 
  10.  * @email  josh_wang23@hotmail.com 
  11.  */  
  12. @Component  
  13. public class DeadLock {    
  14.     
  15.     public static void main(String[] args) {    
  16.         System.out.println(" start the example ----- ");  
  17.         final Object obj_1 = new Object(), obj_2 = new Object();    
  18.             
  19.         Thread t1 = new Thread("t1") {    
  20.             @Override    
  21.             public void run() {    
  22.                 synchronized (obj_1) {    
  23.                     try {    
  24.                         System.out.println("thread t1 start...");  
  25.                         Thread.sleep(3000);    
  26.                     } catch (InterruptedException e) {e.printStackTrace();}    
  27.                         
  28.                     synchronized (obj_2) {    
  29.                         System.out.println("thread t1 done....");    
  30.                     }    
  31.                 }    
  32.             }    
  33.         };    
  34.             
  35.         Thread t2 = new Thread("t2") {    
  36.             @Override    
  37.             public void run() {    
  38.                 synchronized (obj_2) {    
  39.                     try {    
  40.                         System.out.println("thread t2 start...");  
  41.                         Thread.sleep(3000);    
  42.                     } catch (InterruptedException e) {e.printStackTrace();}    
  43.                         
  44.                     synchronized (obj_1) {    
  45.                         System.out.println("thread t2 done...");    
  46.                     }    
  47.                 }    
  48.             }    
  49.         };    
  50.             
  51.         t1.start();    
  52.         t2.start();    
  53.     }    
  54.         
  55. }    

 

    以上DeadLock類是一個死鎖的例子,假使在咱們不知情的狀況下,運行DeadLock後,發現等了N久都沒有在屏幕打印線程完成信息。這個時候咱們就可使用jps查看該程序的pid值和使用jstack來生產堆棧結果問題。

Java代碼   收藏代碼
  1. java -jar deadlock.jar <span style="font-size: 1em; line-height: 1.5;">com.wsheng.aggregator.thread.performance.</span><span style="font-size: 1em; line-height: 1.5;">DeadLock & </span>  

 

Java代碼   收藏代碼
  1. $ jps    
  2.   3076 Jps    
  3.   448 DeadLock    
  4. $ <strong>jstack -l 448 > deadlock.jstack</strong>  

 結果文件deadlock.jstack內容以下：

Java代碼   收藏代碼
  1. 2014-11-29 13:31:06  
  2. Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode):  
  3.   
  4. "Attach Listener" daemon prio=5 tid=0x00007fd9d4002800 nid=0x440b waiting on condition [0x0000000000000000]  
  5.    java.lang.Thread.State: RUNNABLE  
  6.   
  7.    Locked ownable synchronizers:  
  8.     - None  
  9.   
  10. "DestroyJavaVM" prio=5 tid=0x00007fd9d4802000 nid=0x1903 waiting on condition [0x0000000000000000]  
  11.    java.lang.Thread.State: RUNNABLE  
  12.   
  13.    Locked ownable synchronizers:  
  14.     - None  
  15.   
  16. "t2" prio=5 tid=0x00007fd9d30ac000 nid=0x5903 waiting for monitor entry [0x000000011da46000]  
  17.    java.lang.Thread.State: BLOCKED (on object monitor)  
  18.     at DeadLock$2.run(DeadLock.java:38)  
  19.     - waiting to lock <0x00000007aaba7e58> (a java.lang.Object)  
  20.     - locked <0x00000007aaba7e68> (a java.lang.Object)  
  21.   
  22.    Locked ownable synchronizers:  
  23.     - None  
  24.   
  25. "t1" prio=5 tid=0x00007fd9d30ab800 nid=0x5703 waiting for monitor entry [0x000000011d943000]  
  26.    java.lang.Thread.State: BLOCKED (on object monitor)  
  27.     at DeadLock$1.run(DeadLock.java:23)  
  28.     - waiting to lock <0x00000007aaba7e68> (a java.lang.Object)  
  29.     - locked <0x00000007aaba7e58> (a java.lang.Object)  
  30.   
  31.    Locked ownable synchronizers:  
  32.     - None  
  33.   
  34. "Service Thread" daemon prio=5 tid=0x00007fd9d2809000 nid=0x5303 runnable [0x0000000000000000]  
  35.    java.lang.Thread.State: RUNNABLE  
  36.   
  37.    Locked ownable synchronizers:  
  38.     - None  
  39.   
  40. "C2 CompilerThread1" daemon prio=5 tid=0x00007fd9d304e000 nid=0x5103 waiting on condition [0x0000000000000000]  
  41.    java.lang.Thread.State: RUNNABLE  
  42.   
  43.    Locked ownable synchronizers:  
  44.     - None  
  45.   
  46. "C2 CompilerThread0" daemon prio=5 tid=0x00007fd9d2800800 nid=0x4f03 waiting on condition [0x0000000000000000]  
  47.    java.lang.Thread.State: RUNNABLE  
  48.   
  49.    Locked ownable synchronizers:  
  50.     - None  
  51.   
  52. "Signal Dispatcher" daemon prio=5 tid=0x00007fd9d3035000 nid=0x4d03 runnable [0x0000000000000000]  
  53.    java.lang.Thread.State: RUNNABLE  
  54.   
  55.    Locked ownable synchronizers:  
  56.     - None  
  57.   
  58. "Finalizer" daemon prio=5 tid=0x00007fd9d2013000 nid=0x3903 in Object.wait() [0x000000011d18d000]  
  59.    java.lang.Thread.State: WAITING (on object monitor)  
  60.     at java.lang.Object.wait(Native Method)  
  61.     - waiting on <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)  
  62.     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)  
  63.     - locked <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)  
  64.     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)  
  65.     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)  
  66.   
  67.    Locked ownable synchronizers:  
  68.     - None  
  69.   
  70. "Reference Handler" daemon prio=5 tid=0x00007fd9d2012000 nid=0x3703 in Object.wait() [0x000000011d08a000]  
  71.    java.lang.Thread.State: WAITING (on object monitor)  
  72.     at java.lang.Object.wait(Native Method)  
  73.     - waiting on <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)  
  74.     at java.lang.Object.wait(Object.java:503)  
  75.     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)  
  76.     - locked <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)  
  77.   
  78.    Locked ownable synchronizers:  
  79.     - None  
  80.   
  81. "VM Thread" prio=5 tid=0x00007fd9d5011000 nid=0x3503 runnable   
  82.   
  83. "GC task thread#0 (ParallelGC)" prio=5 tid=0x00007fd9d200b000 nid=0x2503 runnable   
  84.   
  85. "GC task thread#1 (ParallelGC)" prio=5 tid=0x00007fd9d200b800 nid=0x2703 runnable   
  86.   
  87. "GC task thread#2 (ParallelGC)" prio=5 tid=0x00007fd9d200c800 nid=0x2903 runnable   
  88.   
  89. "GC task thread#3 (ParallelGC)" prio=5 tid=0x00007fd9d200d000 nid=0x2b03 runnable   
  90.   
  91. "GC task thread#4 (ParallelGC)" prio=5 tid=0x00007fd9d200d800 nid=0x2d03 runnable   
  92.   
  93. "GC task thread#5 (ParallelGC)" prio=5 tid=0x00007fd9d200e000 nid=0x2f03 runnable   
  94.   
  95. "GC task thread#6 (ParallelGC)" prio=5 tid=0x00007fd9d200f000 nid=0x3103 runnable   
  96.   
  97. "GC task thread#7 (ParallelGC)" prio=5 tid=0x00007fd9d200f800 nid=0x3303 runnable   
  98.   
  99. "VM Periodic Task Thread" prio=5 tid=0x00007fd9d3033800 nid=0x5503 waiting on condition   
  100.   
  101. JNI global references: 114  
  102.   
  103.   
  104. <strong>Found one Java-level deadlock:</strong>  
  105. =============================  
  106. <strong>"t2":  
  107.   waiting to lock monitor 0x00007fd9d30aebb8 (object 0x00000007aaba7e58, a java.lang.Object),  
  108.   which is held by "t1"  
  109. "t1":  
  110.   waiting to lock monitor 0x00007fd9d28128b8 (object 0x00000007aaba7e68, a java.lang.Object),  
  111.   which is held by "t2"  
  112.   
  113. Java stack information for the threads listed above:</strong>  
  114. ===================================================  
  115. "t2":  
  116.     at DeadLock$2.run(DeadLock.java:38)  
  117.     - waiting to lock <0x00000007aaba7e58> (a java.lang.Object)  
  118.     - locked <0x00000007aaba7e68> (a java.lang.Object)  
  119. "t1":  
  120.     at DeadLock$1.run(DeadLock.java:23)  
  121.     - waiting to lock <0x00000007aaba7e68> (a java.lang.Object)  
  122.     - locked <0x00000007aaba7e58> (a java.lang.Object)  
  123.   
  124. Found 1 deadlock.  

 從這個結果文件咱們一看到發現了一個死鎖,具體是線程t2在等待線程t1,而線程t1在等待線程t2形成的,同時也記錄了線程的堆棧和代碼行數,經過這個堆棧和行數咱們就能夠去檢查對應的代碼塊,從而發現問題和解決問題。

可經過下面的代碼解決死鎖問題：

Java代碼   收藏代碼
  1. import java.util.concurrent.locks.Lock;  
  2. import java.util.concurrent.locks.ReentrantLock;  
  3.   
  4. /** 
  5.  * Dead lock example 
  6.  *  
  7.  * @author Josh Wang(Sheng) 
  8.  * 
  9.  * @email  josh_wang23@hotmail.com 
  10.  */  
  11. public class DeadLock2Live {    
  12.     
  13.     public static void main(String[] args) {    
  14.         System.out.println(" start the example ----- ");  
  15.         final Lock lock = new ReentrantLock();   
  16.             
  17.         Thread t1 = new Thread("t1") {    
  18.             @Override    
  19.             public void run() {    
  20.                 try {    
  21.                 lock.lock();  
  22.                     Thread.sleep(3000);   
  23.                     System.out.println("thread t1 done.");  
  24.                 } catch (InterruptedException e) {  
  25.                     e.printStackTrace();  
  26.                 } finally {  
  27.                     lock.unlock();  
  28.                 }  
  29.             }  
  30.             };    
  31.             
  32.         Thread t2 = new Thread("t2") {    
  33.             @Override    
  34.             public void run() {    
  35.                 try {    
  36.                     lock.lock();  
  37.                     Thread.sleep(3000);  
  38.                     System.out.println("thread t2 done.");  
  39.                      
  40.   
  41.                 }  catch (InterruptedException e) {  
  42.                     e.printStackTrace();  
  43.                 } finally {  
  44.                     lock.unlock();  
  45.                 }  
  46.             }    
  47.         };    
  48.             
  49.         t1.start();    
  50.         t2.start();    
  51.       
  52. }  
  53.           
  54. }    

 

 二、繼續使用jstack來分析HashMap在多線程狀況下的死鎖問題：

       對於以下代碼，使用10個線程來處理提交的2000個任務，每一個任務會分別循環往hashmap中分別存入和取出1000個數，經過測試發現，程序並不能完整執行完成。[PS:該程序能不能成功執行完，有時也取決於所使用的服務器的運行情況，我在筆記本上測試的時候，大多時候該程序不能成功執行完成，有時會出現CPU轉速加快，發熱等狀況]

 

Java代碼   收藏代碼
  1. import java.util.HashMap;  
  2. import java.util.Map;  
  3. import java.util.concurrent.Callable;  
  4. import java.util.concurrent.ExecutionException;  
  5. import java.util.concurrent.ExecutorService;  
  6. import java.util.concurrent.Executors;  
  7. /** 
  8.  * @author Josh Wang(Sheng) 
  9.  * 
  10.  * @email  josh_wang23@hotmail.com 
  11.  */  
  12. public class HashMapDeadLock implements Callable<Integer> {  
  13.       
  14.     private static ExecutorService threadPool = Executors.newFixedThreadPool(10);  
  15.       
  16.     private static Map<Integer, Integer> results = new HashMap<>();  
  17.   
  18.     @Override  
  19.     public Integer call() throws Exception {  
  20.         results.put(1, 1);  
  21.         results.put(2, 2);  
  22.         results.put(3, 3);  
  23.           
  24.         for (int i = 0; i < 1000; i++) {  
  25.             results.put(i, i);  
  26.         }  
  27.           
  28.         Thread.sleep(1000);  
  29.           
  30.         for (int i= 0; i < 1000; i++) {  
  31.             results.remove(i);  
  32.         }  
  33.           
  34.         System.out.println(" ---- " + Thread.currentThread().getName()  + "     " + results.get(0));  
  35.           
  36.         return results.get(1);  
  37.     }  
  38.       
  39.       
  40. public static void main(String[] args) throws InterruptedException, ExecutionException {  
  41.     try {  
  42.         for (int i = 0; i < 2000; i++) {  
  43.              HashMapDeadLock hashMapDeadLock  = new HashMapDeadLock();  
  44. //           Future<Integer> future = threadPool.submit(hashMapDeadLock);  
  45. //           future.get();  
  46.              threadPool.submit(hashMapDeadLock);  
  47.         }  
  48.      } catch (Exception e) {  
  49.         e.printStackTrace();  
  50.      } finally {  
  51.         threadPool.shutdown();  
  52.      }  
  53.     }  
  54. }  

 

1） 使用jps查看線程可得：

Java代碼   收藏代碼
  1. 43221 Jps  
  2. 30056   
  3. 43125 HashMapDeadLock  

 

2）使用jstack導出多線程棧區信息：

Java代碼   收藏代碼
  1. jstack -l 43125 > hash.jstack   

 

3) hash.jstack的內容以下：

Java代碼   收藏代碼
  1. 2014-11-29 18:14:22  
  2. Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode):  
  3.   
  4. "Attach Listener" daemon prio=5 tid=0x00007f83ee08a000 nid=0x5d07 waiting on condition [0x0000000000000000]  
  5.    java.lang.Thread.State: RUNNABLE  
  6.   
  7.    Locked ownable synchronizers:  
  8.     - None  
  9.   
  10. "DestroyJavaVM" prio=5 tid=0x00007f83eb016800 nid=0x1903 waiting on condition [0x0000000000000000]  
  11.    java.lang.Thread.State: RUNNABLE  
  12.   
  13.    Locked ownable synchronizers:  
  14.     - None  
  15.   
  16. "pool-1-thread-10" prio=5 tid=0x00007f83ec80a000 nid=0x6903 runnable [0x000000011cd19000]  
  17.    java.lang.Thread.State: RUNNABLE  
  18.     at java.util.HashMap.transfer(HashMap.java:601)  
  19.     at java.util.HashMap.resize(HashMap.java:581)  
  20.     at java.util.HashMap.addEntry(HashMap.java:879)  
  21.     at java.util.HashMap.put(HashMap.java:505)  
  22.     <span style="color: #ff0000;"><strong>at HashMapDeadLock.call(HashMapDeadLock.java:30)  
  23.     at HashMapDeadLock.call(HashMapDeadLock.java:1)</strong></span>  
  24.     at java.util.concurrent.FutureTask.run(FutureTask.java:262)  
  25.     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)  
  26.     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)  
  27.     at java.lang.Thread.run(Thread.java:745)  
  28.   
  29.    Locked ownable synchronizers:  
  30.     - <0x00000007aaba84c8> (a java.util.concurrent.ThreadPoolExecutor$Worker)  
  31.   
  32. "Service Thread" daemon prio=5 tid=0x00007f83eb839800 nid=0x5303 runnable [0x0000000000000000]  
  33.    java.lang.Thread.State: RUNNABLE  
  34.   
  35.    Locked ownable synchronizers:  
  36.     - None  
  37.   
  38. "C2 CompilerThread1" daemon prio=5 tid=0x00007f83ee002000 nid=0x5103 waiting on condition [0x0000000000000000]  
  39.    java.lang.Thread.State: RUNNABLE  
  40.   
  41.    Locked ownable synchronizers:  
  42.     - None  
  43.   
  44. "C2 CompilerThread0" daemon prio=5 tid=0x00007f83ee000000 nid=0x4f03 waiting on condition [0x0000000000000000]  
  45.    java.lang.Thread.State: RUNNABLE  
  46.   
  47.    Locked ownable synchronizers:  
  48.     - None  
  49.   
  50. "Signal Dispatcher" daemon prio=5 tid=0x00007f83ec04c800 nid=0x4d03 runnable [0x0000000000000000]  
  51.    java.lang.Thread.State: RUNNABLE  
  52.   
  53.    Locked ownable synchronizers:  
  54.     - None  
  55.   
  56. "Finalizer" daemon prio=5 tid=0x00007f83eb836800 nid=0x3903 in Object.wait() [0x000000011bc58000]  
  57.    java.lang.Thread.State: WAITING (on object monitor)  
  58.     at java.lang.Object.wait(Native Method)  
  59.     - waiting on <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)  
  60.     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)  
  61.     - locked <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)  
  62.     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)  
  63.     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)  
  64.   
  65.    Locked ownable synchronizers:  
  66.     - None  
  67.   
  68. "Reference Handler" daemon prio=5 tid=0x00007f83eb01a800 nid=0x3703 in Object.wait() [0x000000011bb55000]  
  69.    java.lang.Thread.State: WAITING (on object monitor)  
  70.     at java.lang.Object.wait(Native Method)  
  71.     - waiting on <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)  
  72.     at java.lang.Object.wait(Object.java:503)  
  73.     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)  
  74.     - locked <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)  
  75.   
  76.    Locked ownable synchronizers:  
  77.     - None  
  78.   
  79. "VM Thread" prio=5 tid=0x00007f83ed808800 nid=0x3503 runnable   
  80.   
  81. "GC task thread#0 (ParallelGC)" prio=5 tid=0x00007f83ec80d800 nid=0x2503 runnable   
  82.   
  83. "GC task thread#1 (ParallelGC)" prio=5 tid=0x00007f83ec80e000 nid=0x2703 runnable   
  84.   
  85. "GC task thread#2 (ParallelGC)" prio=5 tid=0x00007f83ec001000 nid=0x2903 runnable   
  86.   
  87. "GC task thread#3 (ParallelGC)" prio=5 tid=0x00007f83ec002000 nid=0x2b03 runnable   
  88.   
  89. "GC task thread#4 (ParallelGC)" prio=5 tid=0x00007f83ec002800 nid=0x2d03 runnable   
  90.   
  91. "GC task thread#5 (ParallelGC)" prio=5 tid=0x00007f83ec003000 nid=0x2f03 runnable   
  92.   
  93. "GC task thread#6 (ParallelGC)" prio=5 tid=0x00007f83ec003800 nid=0x3103 runnable   
  94.   
  95. "GC task thread#7 (ParallelGC)" prio=5 tid=0x00007f83ec004800 nid=0x3303 runnable   
  96.   
  97. "VM Periodic Task Thread" prio=5 tid=0x00007f83ec814800 nid=0x5503 waiting on condition   
  98.   
  99. JNI global references: 134  

 4）從紅色高亮部分可看出，代碼中的30行出問題了，即往hashmap中寫入數據出問題了：

Java代碼   收藏代碼
  1. results.put(i, i);  

 

很快就明白由於Hashmap不是線程安全的，因此問題就出在這個地方，咱們可使用線程安全的map即

ConcurrentHashMap後者HashTable來解決該問題：

 

Java代碼   收藏代碼
  1. import java.util.Map;  
  2. import java.util.concurrent.Callable;  
  3. import java.util.concurrent.ConcurrentHashMap;  
  4. import java.util.concurrent.ExecutionException;  
  5. import java.util.concurrent.ExecutorService;  
  6. import java.util.concurrent.Executors;  
  7.   
  8. /** 
  9.  *  
  10.  */  
  11.   
  12. /** 
  13.  * @author Josh Wang(Sheng) 
  14.  * 
  15.  * @email  josh_wang23@hotmail.com 
  16.  */  
  17. public class HashMapDead2LiveLock implements Callable<Integer> {  
  18.       
  19.     private static ExecutorService threadPool = Executors.newFixedThreadPool(10);  
  20.       
  21.     private static Map<Integer, Integer> results = new ConcurrentHashMap<>();  
  22.   
  23.     @Override  
  24.     public Integer call() throws Exception {  
  25.         results.put(1, 1);  
  26.         results.put(2, 2);  
  27.         results.put(3, 3);  
  28.           
  29.         for (int i = 0; i < 1000; i++) {  
  30.             results.put(i, i);  
  31.         }  
  32.           
  33.         Thread.sleep(1000);  
  34.           
  35.         for (int i= 0; i < 1000; i++) {  
  36.             results.remove(i);  
  37.         }  
  38.           
  39.         System.out.println(" ---- " + Thread.currentThread().getName()  + "     " + results.get(0));  
  40.           
  41.         return results.get(1);  
  42.     }  
  43.       
  44.       
  45.     public static void main(String[] args) throws InterruptedException, ExecutionException {  
  46.         try {  
  47.             for (int i = 0; i < 2000; i++) {  
  48.                     HashMapDead2LiveLock hashMapDeadLock  = new HashMapDead2LiveLock();  
  49. //                  Future<Integer> future = threadPool.submit(hashMapDeadLock);  
  50. //                  future.get();  
  51.                     threadPool.submit(hashMapDeadLock);  
  52.                 }  
  53.         } catch (Exception e) {  
  54.             e.printStackTrace();  
  55.         } finally {  
  56.             threadPool.shutdown();  
  57.         }  
  58.       
  59.           
  60.           
  61.           
  62.     }  
  63.   
  64.       
  65. }  

 

改爲ConcurrentHashMap後，從新執行該程序，你會發現很快該程序就執行完了。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程