前提概要：
JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。
现实企业级Java开发中，有时候我们会碰到下面这些问题：
-
OutOfMemoryError，内存不足
-
内存泄露
-
线程死锁
-
锁争用（Lock Contention）
-
Java进程消耗CPU过高
-
......
这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。
基本工具命令
jps
实际中这是最常用的命令，下面要介绍的小工具更多的都是先要使用jps查看出当前有哪些Java进程，获取该Java进程的id后再对该进程进行处理。
jps主要用来输出JVM中运行的进程状态信息。语法格式如下：
jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。
命令行参数选项说明如下：
-q 不输出类名、Jar名和传入main方法的参数
-m 输出传入main方法的参数
-l 输出main类或Jar的全限名
-v 输出传入JVM的参数比如
1、我现在有一个WordCountTopo的Strom程序正在本机运行。
2、使用java -jar deadlock.jar & 启动一个线程死锁的程序
wangsheng@WANGSHENG-PC /E
$ jps -ml
14200 deadlock.jar
13952 com.wsheng.storm.topology.WordCountTopo D://input/ 3
13248 sun.tools.jps.Jps -ml
9728jstack
jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：
jstack [option] pid
jstack [option] executable core
jstack [option] [server-id@]remote-hostname-or-ip命令行参数选项说明如下
-l long listings，会打印出额外的锁信息，在发生死锁时可以用 jstack -l pid 来观察锁持有情况
-m mixed mode，不仅会输出Java堆栈信息，还会输出C/C++堆栈信息（比如Native方法）下面我们来一个实例：
找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。
先找出Java进程ID，服务器上的Java应用名称为wordcount.jar：
[root@storm-master home]# ps -ef | grep wordcount | grep -v grep
root 2860 2547 13 02:09 pts/0 00:02:03 java -jar wordcount.jar /home/input 3得到进程ID为2860（也可以使用其它方式得到java的进程号）,
找出该进程内最耗费CPU的线程，可以使用如下3个命令，这里我们使用第3个命令得出如下结果：
TIME列就是各个Java线程耗费的CPU时间，显然CPU时间最长的是ID为2968的线程，用
printf "%x\n" 2968得到2968的十六进制值为b98，下面会用到。
终于轮到jstack上场了，它用来输出进程2860的堆栈信息，然后根据线程ID的十六进制值grep，如下：
[root@storm-master home]# jstack 2860 | grep b98
"SessionTracker" prio=10 tid=0x00007f55a44e4800 nid=0xb53 in Object.wait() [0x00007f558e06c000可以看到CPU消耗在SessionTracker这个类的Object.wait()，于是就能很容易的定位到相关的代码了。
jmap和 jhat
jmap用来查看堆内存使用状况，一般结合jhat使用。
jmap语法格式如下：
jmap [option] pid
jmap [option] executable core
jmap [option] [server-id@]remote-hostname-or-ip如果运行在64位JVM上，由于linux操作系统的不同，可能需要指定-J-d64命令选项参数。
打印进程的类加载器和类加载器加载的持久代对象信息： jmap -permstat pid
个人感觉这个不是太有用
输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，如图：
查看进程堆内存使用情况:包括使用的GC算法、堆配置参数和各代中堆内存使用：jmap -heap pid
比如下面的例子
[root@storm-master home]# jmap -heap 2860
Attaching to process ID 2860, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.45-b01using thread-local object allocation.
Mark Sweep Compact GCHeap Configuration:MinHeapFreeRatio = 40MaxHeapFreeRatio = 70MaxHeapSize = 257949696 (246.0MB)NewSize = 1310720 (1.25MB)MaxNewSize = 17592186044415 MBOldSize = 5439488 (5.1875MB)NewRatio = 2SurvivorRatio = 8PermSize = 21757952 (20.75MB)MaxPermSize = 85983232 (82.0MB)Heap Usage:
New Generation (Eden + 1 Survivor Space):capacity = 12189696 (11.625MB)used = 6769392 (6.4557952880859375MB)free = 5420304 (5.1692047119140625MB)55.53372290826613% used
Eden Space:capacity = 10878976 (10.375MB)used = 6585608 (6.280525207519531MB)free = 4293368 (4.094474792480469MB)60.53518272307982% used
From Space:capacity = 1310720 (1.25MB)used = 183784 (0.17527008056640625MB)free = 1126936 (1.0747299194335938MB)14.0216064453125% used
To Space:capacity = 1310720 (1.25MB)used = 0 (0.0MB)free = 1310720 (1.25MB)0.0% used
tenured generation:capacity = 26619904 (25.38671875MB)used = 15785896 (15.054603576660156MB)free = 10834008 (10.332115173339844MB)59.30110040967841% used
Perm Generation:capacity = 33554432 (32.0MB)used = 33323352 (31.779624938964844MB)free = 231080 (0.22037506103515625MB)99.31132793426514% used查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象：jmap -histo[:live] pid
[root@storm-master Desktop]# jmap -histo 2860num #instances #bytes class name
----------------------------------------------1: 13917 11432488 [B2: 6117 6181448 <instanceKlassKlass>3: 39520 6004504 <constMethodKlass>4: 6117 5517072 <constantPoolKlass>5: 39520 5383280 <methodKlass>6: 5148 3150944 <constantPoolCacheKlass>7: 29954 2810640 [C8: 50179 2469272 <symbolKlass>9: 42122 1791704 [Ljava.lang.Object;10: 1804 961464 <methodDataKlass>11: 11747 941200 [Ljava.util.HashMap$Entry;12: 28786 921152 java.lang.String13: 6347 660088 java.lang.Class14: 7374 625616 [S15: 11740 563520 java.util.HashMap16: 23447 562728 clojure.lang.PersistentHashMap$BitmapIndexedNode17: 10980 351360 clojure.lang.Symbol18: 8544 341760 java.lang.ref.SoftReference19: 8028 336632 [[I20: 3944 283968 java.lang.reflect.Constructor21: 4744 227712 java.nio.HeapByteBuffer22: 6854 219328 java.util.AbstractList$Itr23: 2185 195192 [I24: 3854 184992 java.nio.HeapCharBuffer25: 5500 176000 java.util.concurrent.ConcurrentHashMap$HashEntryclass name是对象类型，说明如下:
B byte
C char
D double
F float
I int
J long
Z boolean
[ 数组，如[I表示int[]
[L+类名 其他对象还有一个很常用的情况是：用jmap把进程内存使用情况dump到文件中，再用jhat分析查看。需要注意的是 dump出来的文件还可以用MAT、VisualVM等工具查看。
jmap进行dump命令格式如下：
jmap -dump:format=b,file=dumpFileName pid我一样地对上面进程ID为2860进行Dump：
[root@storm-master Desktop]# jmap -dump:format=b,file=/home/dump.dat 2860
Dumping heap to /home/dump.dat ...
Heap dump file created然后使用jhat来对上面dump出来的内容进行分析
[root@storm-master Desktop]# jhat -port 8888 /home/dump.dat
Reading from /home/dump.dat...
Dump file created Sat Aug 01 04:21:12 PDT 2015
Snapshot read, resolving...
Resolving 411123 objects...
Chasing references, expect 82 dots..................................................................................
Eliminating duplicate references..................................................................................
Snapshot resolved.
Started HTTP server on port 8888
Server is ready.注意如果Dump文件太大，可能需要加上-J-Xmx512m参数以指定最大堆内存，即jhat -J-Xmx512m -port 8888 /home/dump.dat。然后就可以在浏览器中输入主机地址:8888查看了：
点击每一个蓝色的超链接，你都会看到其相关更具体的信息，而最后一项更是支持OQL（对象查询语言）。
jstat: 看看各个区内存和GC的情况
语法格式如下：
jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]vmid是Java虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为6：
[root@storm-master Desktop]# jstat -gc 2860 250 6
要明白上面各列的意义，先看JVM堆内存布局：
可以看出：
现在来解释各列含义：
hprof
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 -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是可选参数,它可以显示线程阻塞/死锁情况
package com.wsheng.aggregator.thread.performance;import org.springframework.stereotype.Component;/*** Dead lock example* * @author Josh Wang(Sheng)** @email josh_wang23@hotmail.com*/
@Component
public class DeadLock { public static void main(String[] args) { System.out.println(" start the example ----- ");final Object obj_1 = new Object(), obj_2 = new Object(); Thread t1 = new Thread("t1") { @Override public void run() { synchronized (obj_1) { try { System.out.println("thread t1 start...");Thread.sleep(3000); } catch (InterruptedException e) {e.printStackTrace();} synchronized (obj_2) { System.out.println("thread t1 done...."); } } } }; Thread t2 = new Thread("t2") { @Override public void run() { synchronized (obj_2) { try { System.out.println("thread t2 start...");Thread.sleep(3000); } catch (InterruptedException e) {e.printStackTrace();} synchronized (obj_1) { System.out.println("thread t2 done..."); } } } }; t1.start(); t2.start(); } }
以上DeadLock类是一个死锁的例子,假使在我们不知情的情况下,运行DeadLock后,发现等了N久都没有在屏幕打印线程完成信息。这个时候我们就可以使用jps查看该程序的pid值和使用jstack来生产堆栈结果问题。
结果文件deadlock.jstack内容如下：
2014-11-29 13:31:06
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode):"Attach Listener" daemon prio=5 tid=0x00007fd9d4002800 nid=0x440b waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"DestroyJavaVM" prio=5 tid=0x00007fd9d4802000 nid=0x1903 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"t2" prio=5 tid=0x00007fd9d30ac000 nid=0x5903 waiting for monitor entry [0x000000011da46000]java.lang.Thread.State: BLOCKED (on object monitor)at DeadLock$2.run(DeadLock.java:38)- waiting to lock <0x00000007aaba7e58> (a java.lang.Object)- locked <0x00000007aaba7e68> (a java.lang.Object)Locked ownable synchronizers:- None"t1" prio=5 tid=0x00007fd9d30ab800 nid=0x5703 waiting for monitor entry [0x000000011d943000]java.lang.Thread.State: BLOCKED (on object monitor)at DeadLock$1.run(DeadLock.java:23)- waiting to lock <0x00000007aaba7e68> (a java.lang.Object)- locked <0x00000007aaba7e58> (a java.lang.Object)Locked ownable synchronizers:- None"Service Thread" daemon prio=5 tid=0x00007fd9d2809000 nid=0x5303 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread1" daemon prio=5 tid=0x00007fd9d304e000 nid=0x5103 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread0" daemon prio=5 tid=0x00007fd9d2800800 nid=0x4f03 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Signal Dispatcher" daemon prio=5 tid=0x00007fd9d3035000 nid=0x4d03 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Finalizer" daemon prio=5 tid=0x00007fd9d2013000 nid=0x3903 in Object.wait() [0x000000011d18d000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)- locked <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)Locked ownable synchronizers:- None"Reference Handler" daemon prio=5 tid=0x00007fd9d2012000 nid=0x3703 in Object.wait() [0x000000011d08a000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Object.java:503)at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)- locked <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)Locked ownable synchronizers:- None"VM Thread" prio=5 tid=0x00007fd9d5011000 nid=0x3503 runnable "GC task thread#0 (ParallelGC)" prio=5 tid=0x00007fd9d200b000 nid=0x2503 runnable "GC task thread#1 (ParallelGC)" prio=5 tid=0x00007fd9d200b800 nid=0x2703 runnable "GC task thread#2 (ParallelGC)" prio=5 tid=0x00007fd9d200c800 nid=0x2903 runnable "GC task thread#3 (ParallelGC)" prio=5 tid=0x00007fd9d200d000 nid=0x2b03 runnable "GC task thread#4 (ParallelGC)" prio=5 tid=0x00007fd9d200d800 nid=0x2d03 runnable "GC task thread#5 (ParallelGC)" prio=5 tid=0x00007fd9d200e000 nid=0x2f03 runnable "GC task thread#6 (ParallelGC)" prio=5 tid=0x00007fd9d200f000 nid=0x3103 runnable "GC task thread#7 (ParallelGC)" prio=5 tid=0x00007fd9d200f800 nid=0x3303 runnable "VM Periodic Task Thread" prio=5 tid=0x00007fd9d3033800 nid=0x5503 waiting on condition JNI global references: 114Found one Java-level deadlock:
=============================
"t2":waiting to lock monitor 0x00007fd9d30aebb8 (object 0x00000007aaba7e58, a java.lang.Object),which is held by "t1"
"t1":waiting to lock monitor 0x00007fd9d28128b8 (object 0x00000007aaba7e68, a java.lang.Object),which is held by "t2"Java stack information for the threads listed above:
===================================================
"t2":at DeadLock$2.run(DeadLock.java:38)- waiting to lock <0x00000007aaba7e58> (a java.lang.Object)- locked <0x00000007aaba7e68> (a java.lang.Object)
"t1":at DeadLock$1.run(DeadLock.java:23)- waiting to lock <0x00000007aaba7e68> (a java.lang.Object)- locked <0x00000007aaba7e58> (a java.lang.Object)Found 1 deadlock.从这个结果文件我们一看到发现了一个死锁,具体是线程t2在等待线程t1,而线程t1在等待线程t2造成的,同时也记录了线程的堆栈和代码行数,通过这个堆栈和行数我们就可以去检查对应的代码块,从而发现问题和解决问题。
可通过下面的代码解决死锁问题：
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;/*** Dead lock example* * @author Josh Wang(Sheng)** @email josh_wang23@hotmail.com*/
public class DeadLock2Live { public static void main(String[] args) { System.out.println(" start the example ----- ");final Lock lock = new ReentrantLock(); Thread t1 = new Thread("t1") { @Override public void run() { try { lock.lock();Thread.sleep(3000); System.out.println("thread t1 done.");} catch (InterruptedException e) {e.printStackTrace();} finally {lock.unlock();}}}; Thread t2 = new Thread("t2") { @Override public void run() { try { lock.lock();Thread.sleep(3000);System.out.println("thread t2 done.");} catch (InterruptedException e) {e.printStackTrace();} finally {lock.unlock();}} }; t1.start(); t2.start(); }}
继续使用jstack来分析HashMap在多线程情况下的死锁问题：
对于如下代码，使用10个线程来处理提交的2000个任务，每个任务会分别循环往hashmap中分别存入和取出1000个数，通过测试发现，程序并不能完整执行完成。[PS:该程序能不能成功执行完，有时也取决于所使用的服务器的运行状况，我在笔记本上测试的时候，大多时候该程序不能成功执行完成，有时会出现CPU转速加快，发热等情况]
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
/*** @author Josh Wang(Sheng)** @email josh_wang23@hotmail.com*/
public class HashMapDeadLock implements Callable<Integer> {private static ExecutorService threadPool = Executors.newFixedThreadPool(10);private static Map<Integer, Integer> results = new HashMap<>();@Overridepublic Integer call() throws Exception {results.put(1, 1);results.put(2, 2);results.put(3, 3);for (int i = 0; i < 1000; i++) {results.put(i, i);}Thread.sleep(1000);for (int i= 0; i < 1000; i++) {results.remove(i);}System.out.println(" ---- " + Thread.currentThread().getName() + " " + results.get(0));return results.get(1);}public static void main(String[] args) throws InterruptedException, ExecutionException {try {for (int i = 0; i < 2000; i++) {HashMapDeadLock hashMapDeadLock = new HashMapDeadLock();
// Future<Integer> future = threadPool.submit(hashMapDeadLock);
// future.get();threadPool.submit(hashMapDeadLock);}} catch (Exception e) {e.printStackTrace();} finally {threadPool.shutdown();}}
} 1） 使用jps查看线程可得：
43221 Jps
30056
43125 HashMapDeadLock2）使用jstack导出多线程栈区信息：
3) hash.jstack的内容如下：
2014-11-29 18:14:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode):"Attach Listener" daemon prio=5 tid=0x00007f83ee08a000 nid=0x5d07 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"DestroyJavaVM" prio=5 tid=0x00007f83eb016800 nid=0x1903 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"pool-1-thread-10" prio=5 tid=0x00007f83ec80a000 nid=0x6903 runnable [0x000000011cd19000]java.lang.Thread.State: RUNNABLEat java.util.HashMap.transfer(HashMap.java:601)at java.util.HashMap.resize(HashMap.java:581)at java.util.HashMap.addEntry(HashMap.java:879)at java.util.HashMap.put(HashMap.java:505)at HashMapDeadLock.call(HashMapDeadLock.java:30)at HashMapDeadLock.call(HashMapDeadLock.java:1)at java.util.concurrent.FutureTask.run(FutureTask.java:262)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)at java.lang.Thread.run(Thread.java:745)Locked ownable synchronizers:- <0x00000007aaba84c8> (a java.util.concurrent.ThreadPoolExecutor$Worker)"Service Thread" daemon prio=5 tid=0x00007f83eb839800 nid=0x5303 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread1" daemon prio=5 tid=0x00007f83ee002000 nid=0x5103 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread0" daemon prio=5 tid=0x00007f83ee000000 nid=0x4f03 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Signal Dispatcher" daemon prio=5 tid=0x00007f83ec04c800 nid=0x4d03 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Finalizer" daemon prio=5 tid=0x00007f83eb836800 nid=0x3903 in Object.wait() [0x000000011bc58000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)- locked <0x00000007aaa85608> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)Locked ownable synchronizers:- None"Reference Handler" daemon prio=5 tid=0x00007f83eb01a800 nid=0x3703 in Object.wait() [0x000000011bb55000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Object.java:503)at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)- locked <0x00000007aaa85190> (a java.lang.ref.Reference$Lock)Locked ownable synchronizers:- None"VM Thread" prio=5 tid=0x00007f83ed808800 nid=0x3503 runnable "GC task thread#0 (ParallelGC)" prio=5 tid=0x00007f83ec80d800 nid=0x2503 runnable "GC task thread#1 (ParallelGC)" prio=5 tid=0x00007f83ec80e000 nid=0x2703 runnable "GC task thread#2 (ParallelGC)" prio=5 tid=0x00007f83ec001000 nid=0x2903 runnable "GC task thread#3 (ParallelGC)" prio=5 tid=0x00007f83ec002000 nid=0x2b03 runnable "GC task thread#4 (ParallelGC)" prio=5 tid=0x00007f83ec002800 nid=0x2d03 runnable "GC task thread#5 (ParallelGC)" prio=5 tid=0x00007f83ec003000 nid=0x2f03 runnable "GC task thread#6 (ParallelGC)" prio=5 tid=0x00007f83ec003800 nid=0x3103 runnable "GC task thread#7 (ParallelGC)" prio=5 tid=0x00007f83ec004800 nid=0x3303 runnable "VM Periodic Task Thread" prio=5 tid=0x00007f83ec814800 nid=0x5503 waiting on condition JNI global references: 1344）从上边部分可看出，代码中的30行出问题了，即往hashmap中写入数据出问题了：
很快就明白因为Hashmap不是线程安全的，所以问题就出在这个地方，我们可以使用线程安全的map即
ConcurrentHashMap后者HashTable来解决该问题：
import java.util.Map;
import java.util.concurrent.Callable;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;/*** *//*** @author Josh Wang(Sheng)** @email josh_wang23@hotmail.com*/
public class HashMapDead2LiveLock implements Callable<Integer> {private static ExecutorService threadPool = Executors.newFixedThreadPool(10);private static Map<Integer, Integer> results = new ConcurrentHashMap<>();@Overridepublic Integer call() throws Exception {results.put(1, 1);results.put(2, 2);results.put(3, 3);for (int i = 0; i < 1000; i++) {results.put(i, i);}Thread.sleep(1000);for (int i= 0; i < 1000; i++) {results.remove(i);}System.out.println(" ---- " + Thread.currentThread().getName() + " " + results.get(0));return results.get(1);}public static void main(String[] args) throws InterruptedException, ExecutionException {try {for (int i = 0; i < 2000; i++) {HashMapDead2LiveLock hashMapDeadLock = new HashMapDead2LiveLock();
// Future<Integer> future = threadPool.submit(hashMapDeadLock);
// future.get();threadPool.submit(hashMapDeadLock);}} catch (Exception e) {e.printStackTrace();} finally {threadPool.shutdown();}}}改成ConcurrentHashMap后，重新执行该程序，你会发现很快该程序就执行完了。