温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
& 新增词汇：(共23个)
& &behavior& n. 行为，举止
confidence& n.& 信心；信任
hometown& n. 家乡， 故乡&
humourous&& adj.& 幽默的，风趣的
including& prep. 包括；包含
maths (美math)&
naughty& adj.& 顽皮的&
player n. 运动员，选手；演奏者&
responsibility&&& n. 责任，职责，责任心
rude& adj. 无理的，粗鲁的&
最后登录加载中...
this.p={b:2,ua:19, ub:'-1000',us:'他', friendstatus:'none',followstatus:'unFollow',hmcon:'0',aShowT:'0',guideId:6};
积分 ${data.totalScore} 分，距离下一等级还有 ${data.nextGradeNeedScore}分
心情随笔列表加载中...
this.p={b:2,n:5,r:'http://jpsyclass13.blog.163.com/blog/#m=1&c=',mset:'000',mcon:'',srk:-100};
{if defined('fl')&&fl.length>0} {list fl as x}
${x.content|xescape:x.id,x.moveFrom} ${x.publishTime|xtime}
{if x.moveFrom&&x.moveFrom=='wap'} && {/if} {if x.moveFrom&&x.moveFrom=='mobile'} && {/if}
{/list} {else} 暂无心情随笔记录！ {/if}
博友列表加载中...
this.p={b:2,m:0};
发现好博客
列表加载中...
this.p={b:2,cn:12,ct:12};
列表加载中...
this.p={b:2,cn:15};
我要留言 & &
& 留言列表加载中...
this.p={b:2,nv:false,cn:5,ct:5};
& & & & & &
网易公司版权所有&&
{list x.l as y}
{/list} {/list}
{if defined('wl')} {list wl as x}{/list} {/if}温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
&&& 人们对珍贵这个词的定义是如何的？在于数量？在于价格？不，在那件事过后，在我心中对“珍贵”这个词的定义变得清晰和明显。 &&&&当古诗文竞赛成绩出来后，我得知我名落孙山，而我又发现我们班参加这次竞赛的其他四个同学中三都进入了复赛，我心情就犹如当时的天气，阴阴沉沉，被一层阴霾笼罩着，想：这是我的水平吗？区区一个竞赛我居然都没能晋级，我怎么会这样呢！回到家后，吃过晚饭，爸爸见我垂头丧气的样子，便说：“带你去小区后面的空地玩玩，如何？”我不想让爸爸扫兴，只好无精打采地回答：“ 好吧。”由于刚刚下完雨，空气十分清新，周围的植物经历了风雨的洗礼，都显得生机勃勃勃。我走在泥路上，望着这一派独有风味的景象，心情稍微放松了些。这时，爸爸忽然说：“你能找到我们走过来时的脚印吗？”我低下头望着地，很快找到了，并指
& 嵇诗雯 小小的我 你认识我吗？我，一双水汪汪的大眼睛，一个好看的鼻子，在鼻子的下方有一张能说会道的嘴。我喜欢唱歌，画画，喜欢站在舞台上有成就感的自己，喜欢弹琴，喜欢尝试一切新鲜的事物，跟喜欢朴实的自己。　　　
从小由于妈妈的严格管教，我很听话，凡是见过我的长辈们无不夸我是一个听话，懂事的好孩子。而在家里我却很活泼，很爱笑，喜欢看电视，嬉笑怒骂，无所顾忌。在学校里时而高谈阔论，海吹神侃；时而被某君的妙语连珠逗得哈哈大笑，我身上仿佛放下千斤重担，一片轻松。　　 　　我很胆小。记得有一次我妈妈和我在车站接叔叔，在去的路上
& 嵇诗雯 我小学五年的朋友 小时候，我以为朋友就是与我一起分享食物，与我一起玩耍的伙伴，对真正的朋友并没有太多的理解与认识。后来，我认识了石昕旖，我们朝夕相伴，一起学习，一起玩耍，一起感受成长的快乐与痛苦，成为真正的好朋友。
去年暑假的一天中午，我正要吃午饭，电话铃声急促的响了起来，我赶紧抓起电话听筒，原来是石昕旖“我家养了一只小狗，但她不停地再叫，你能不能来我家帮帮我啊？” 石昕旖焦急地说。 “你不知道现在是什么时间了吗，老大？能不能等我吃完了饭呢？”我很不客气地把他噎了回去，“哦，抱歉，我光顾着照顾她，忘看时间。对不起，那就等你吃完了饭再来，可以吗？” 石昕旖不好意思地说，“我知
&嵇诗雯 我的幸福家庭 我有一个温馨而快乐的家，在这个家里，到处都充满了爱，充满了欢乐。爸爸的幽默，妈妈的和蔼，使我们这个家更加温暖。
一个阳光明媚的早晨，我和爸爸妈妈坐了一夜的火车，来到了首都北京。刚一到，就听到一个喜讯：在北环路上的快乐超市旁，有一个“家庭大比拼”的游戏，九点开始。我和爸爸妈妈把东西急忙放到宾馆，就去报名了。游戏马上就要开始了！
第一局：父母将孩子夹在中间，腿用绳子绑着，三人一起走，第一个到达终点的家庭胜利。准备好后，一声枪响，我与爸爸妈妈迅速向终点冲去，由于我走的规律总和爸爸妈妈的不一置，爸爸
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 门其实开着 &&&&&& 我之所以能将数学题较好地解答出来，是因为我敢去算。其实题并不难，有些同学算不出来，那是因为他们没有敢去推开那扇虚掩着的装有答案的门。 　　我以前也不会去开那扇门，只是由于曾经的那件事，我才终于战胜了自己，从而看到门里面所发出的光亮。打开记忆的大门，敞开记忆的心扉，在我的脑海里，在我记忆的长河里，它就像昨天所发生的事情一样。当时的那些情景，至今仍能清晰地浮现在我的眼前。 　　那一天，数学老师给我们发了试卷，让我们下午放学的时候交上，同时老师还强调做出最后一道题的同学会有奖。自习课还有十分钟就要结束了，这就意味着我在十分钟前必须要交上试卷，可是我还剩下最后
最后登录加载中...
this.p={b:2,ua:8, ub:'-1000',us:'她', friendstatus:'none',followstatus:'unFollow',hmcon:'',aShowT:'0',guideId:4};
积分 ${data.totalScore} 分，距离下一等级还有 ${data.nextGradeNeedScore}分
心情随笔列表加载中...
this.p={b:2,n:5,r:'http://jp201005.blog.163.com/blog/#m=1&c=',mset:'000',mcon:'',srk:-100};
{if defined('fl')&&fl.length>0} {list fl as x}
${x.content|xescape:x.id,x.moveFrom} ${x.publishTime|xtime}
{if x.moveFrom&&x.moveFrom=='wap'} && {/if} {if x.moveFrom&&x.moveFrom=='mobile'} && {/if}
{/list} {else} 暂无心情随笔记录！ {/if}
博友列表加载中...
this.p={b:2,m:0};
发现好博客
列表加载中...
this.p={b:2,cn:12,ct:12};
列表加载中...
this.p={b:2,cn:15};
我要留言 & &
& 留言列表加载中...
this.p={b:2,nv:false,cn:5,ct:5};
& & & & & &
网易公司版权所有&&
{list x.l as y}
{/list} {/list}
{if defined('wl')} {list wl as x}{/list} {/if}博客分类：
前提概要：
JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。
现实企业级Java开发中，有时候我们会碰到下面这些问题：
OutOfMemoryError，内存不足
锁争用（Lock Contention）
Java进程消耗CPU过高
这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。
一、 jps(Java Virtual Machine Process Status Tool)
： 基础工具
实际中这是最常用的命令，下面要介绍的小工具更多的都是先要使用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
14200 deadlock.jar
13952 com.wsheng.storm.topology.WordCountTopo D:
13248 sun.tools.jps.Jps -ml
二、 jstack
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方法）
jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。
下面我们来一个实例：
找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。
第一步： 先找出Java进程ID，服务器上的Java应用名称为wordcount.jar：
[root@storm-master home]# ps -ef | grep wordcount | grep -v grep
2547 13 02:09 pts/0
00:02:03 java -jar wordcount.jar /home/input 3
得到进程ID为2860,
第二步:找出该进程内最耗费CPU的线程，可以使用如下3个命令，这里我们使用第3个命令得出如下结果：
1）ps -Lfp pid ： 即 ps -Lfp 2860
2）ps -mp pid -o THREAD, tid, time ：即 ps -mp 2860 -o THREAD,tid,time
3）top -Hp pid： 即 top -Hp 2860
用第三个，输出如下：
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=0xe4800 nid=0xb53 in Object.wait() [0xc000
可以看到CPU消耗在SessionTracker这个类的Object.wait()，于是就能很容易的定位到相关的代码了。
三、 jmap（Memory Map）和 jhat（Java Heap Analysis Tool）：
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命令选项参数。
1、打印进程的类加载器和类加载器加载的持久代对象信息： jmap -permstat pid
个人感觉这个不是太有用
输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，如图：
2、查看进程堆内存使用情况:包括使用的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-b01
using thread-local object allocation.
Mark Sweep Compact GC
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize
= 1310720 (1.25MB)
MaxNewSize
= 5439488 (5.1875MB)
SurvivorRatio
MaxPermSize
Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity =
(11.625MB)
= 6769392 (6.9375MB)
= 5420304 (5.0625MB)
55.13% used
Eden Space:
capacity =
(10.375MB)
= 6585608 (6.531MB)
= 4293368 (4.469MB)
60.82% used
From Space:
capacity = 1310720 (1.25MB)
= 183784 (0.40625MB)
= 1126936 (1.5938MB)
14.5% used
capacity = 1310720 (1.25MB)
= 0 (0.0MB)
= 1310720 (1.25MB)
tenured generation:
capacity =
(15.156MB)
(10.844MB)
59.41% used
Perm Generation:
capacity =
(31.844MB)
= 231080 (0.15625MB)
99.14% used
3、查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象：jmap -histo[:live] pid
[root@storm-master Desktop]# jmap -histo 2860
#instances
class name
----------------------------------------------
&instanceKlassKlass&
&constMethodKlass&
&constantPoolKlass&
&methodKlass&
&constantPoolCacheKlass&
&symbolKlass&
[Ljava.lang.O
&methodDataKlass&
[Ljava.util.HashMap$E
java.lang.String
java.lang.Class
java.util.HashMap
clojure.lang.PersistentHashMap$BitmapIndexedNode
clojure.lang.Symbol
java.lang.ref.SoftReference
java.lang.reflect.Constructor
java.nio.HeapByteBuffer
java.util.AbstractList$Itr
java.nio.HeapCharBuffer
java.util.concurrent.ConcurrentHashMap$HashEntry
class name是对象类型，说明如下:
数组，如[I表示int[]
[L+类名 其他对象
4、还有一个很常用的情况是：用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（JVM统计监测工具）: 看看各个区内存和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堆内存布局：
可以看出：
堆内存 = 年轻代 + 年老代 + 永久代
年轻代 = Eden区 + 两个Survivor区（From和To）
现在来解释各列含义：
S0C、S1C、S0U、S1U：Survivor 0/1区容量（Capacity）和使用量（Used）
EC、EU：Eden区容量和使用量
OC、OU：年老代容量和使用量
PC、PU：永久代容量和使用量
YGC、YGT：年轻代GC次数和GC耗时
FGC、FGCT：Full GC次数和Full GC耗时
GCT：GC总耗时
五、hprof（Heap/CPU Profiling Tool）：
hprof能够展现CPU使用率，统计堆内存使用情况。
：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[=options] ToBeProfiledClass
java -Xrunprof[:options] ToBeProfiledClass
javac -J-agentlib:hprof[=options] ToBeProfiledClass
完整的命令选项如下：
Option Name and Value
Description
---------------------
-----------
heap=dump|sites|all
heap profiling
cpu=samples|times|old
monitor=y|n
monitor contention
format=a|b
text(txt) or binary output
file=&file&
write data to file
java.hprof[.txt]
net=&host&:&port&
send data over a socket
depth=&size&
stack trace depth
interval=&ms&
sample interval in ms
cutoff=&value&
output cutoff point
lineno=y|n
line number in traces?
thread=y|n
thread in traces?
dump on exit?
Solaris micro state accounting n
force output to &file&
verbose=y|n
print messages about dumps
- 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性能调优工具来进行性能诊断。
1、使用jstack来分析死锁问题：
上面说明中提到 jstack主要用来查看某个Java进程内的线程堆栈信息,您可以使用它查明问题。jstack [-l] &pid&,pid可以通过使用jps命令来查看当前Java程序的pid值,-l是可选参数,它可以显示线程阻塞/死锁情况
package com.wsheng.aggregator.thread.
import org.springframework.stereotype.C
@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") {
public void run() {
synchronized (obj_1) {
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") {
public void run() {
synchronized (obj_2) {
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来生产堆栈结果问题。
java -jar deadlock.jar com.wsheng.aggregator.thread.performance.DeadLock & &/span&
448 DeadLock
$ jstack -l 448 & deadlock.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=0x02800 nid=0x440b waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"DestroyJavaVM" prio=5 tid=0x02000 nid=0x1903 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"t2" prio=5 tid=0x0ac000 nid=0x5903 waiting for monitor entry [0xda46000]
java.lang.Thread.State: BLOCKED (on object monitor)
at DeadLock$2.run(DeadLock.java:38)
- waiting to lock &0xaaba7e58& (a java.lang.Object)
- locked &0xaaba7e68& (a java.lang.Object)
Locked ownable synchronizers:
"t1" prio=5 tid=0x0ab800 nid=0x5703 waiting for monitor entry [0x3000]
java.lang.Thread.State: BLOCKED (on object monitor)
at DeadLock$1.run(DeadLock.java:23)
- waiting to lock &0xaaba7e68& (a java.lang.Object)
- locked &0xaaba7e58& (a java.lang.Object)
Locked ownable synchronizers:
"Service Thread" daemon prio=5 tid=0x09000 nid=0x5303 runnable [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"C2 CompilerThread1" daemon prio=5 tid=0x0e000 nid=0x5103 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"C2 CompilerThread0" daemon prio=5 tid=0x00800 nid=0x4f03 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"Signal Dispatcher" daemon prio=5 tid=0x05000 nid=0x4d03 runnable [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"Finalizer" daemon prio=5 tid=0x03000 nid=0x3903 in Object.wait() [0xd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on &0xaaa85608& (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked &0xaaa85608& (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:
"Reference Handler" daemon prio=5 tid=0x02000 nid=0x3703 in Object.wait() [0xa000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on &0xaaa85190& (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 &0xaaa85190& (a java.lang.ref.Reference$Lock)
Locked ownable synchronizers:
"VM Thread" prio=5 tid=0x01000 nid=0x3503 runnable
"GC task thread#0 (ParallelGC)" prio=5 tid=0x0b000 nid=0x2503 runnable
"GC task thread#1 (ParallelGC)" prio=5 tid=0x0b800 nid=0x2703 runnable
"GC task thread#2 (ParallelGC)" prio=5 tid=0x0c800 nid=0x2903 runnable
"GC task thread#3 (ParallelGC)" prio=5 tid=0x0d000 nid=0x2b03 runnable
"GC task thread#4 (ParallelGC)" prio=5 tid=0x0d800 nid=0x2d03 runnable
"GC task thread#5 (ParallelGC)" prio=5 tid=0x0e000 nid=0x2f03 runnable
"GC task thread#6 (ParallelGC)" prio=5 tid=0x0f000 nid=0x3103 runnable
"GC task thread#7 (ParallelGC)" prio=5 tid=0x0f800 nid=0x3303 runnable
"VM Periodic Task Thread" prio=5 tid=0x03800 nid=0x5503 waiting on condition
JNI global references: 114
Found one Java-level deadlock:
=============================
waiting to lock monitor 0x0aebb8 (object 0xaaba7e58, a java.lang.Object),
which is held by "t1"
waiting to lock monitor 0x028b8 (object 0xaaba7e68, a java.lang.Object),
which is held by "t2"
Java stack information for the threads listed above:
===================================================
at DeadLock$2.run(DeadLock.java:38)
- waiting to lock &0xaaba7e58& (a java.lang.Object)
- locked &0xaaba7e68& (a java.lang.Object)
at DeadLock$1.run(DeadLock.java:23)
- waiting to lock &0xaaba7e68& (a java.lang.Object)
- locked &0xaaba7e58& (a java.lang.Object)
Found 1 deadlock.
从这个结果文件我们一看到发现了一个死锁,具体是线程t2在等待线程t1,而线程t1在等待线程t2造成的,同时也记录了线程的堆栈和代码行数,通过这个堆栈和行数我们就可以去检查对应的代码块,从而发现问题和解决问题。
可通过下面的代码解决死锁问题：
import java.util.concurrent.locks.L
import java.util.concurrent.locks.ReentrantL
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") {
public void run() {
lock.lock();
Thread.sleep(3000);
System.out.println("thread t1 done.");
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
Thread t2 = new Thread("t2") {
public void run() {
lock.lock();
Thread.sleep(3000);
System.out.println("thread t2 done.");
catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
t1.start();
t2.start();
2、继续使用jstack来分析HashMap在多线程情况下的死锁问题：
对于如下代码，使用10个线程来处理提交的2000个任务，每个任务会分别循环往hashmap中分别存入和取出1000个数，通过测试发现，程序并不能完整执行完成。[PS:该程序能不能成功执行完，有时也取决于所使用的服务器的运行状况，我在笔记本上测试的时候，大多时候该程序不能成功执行完成，有时会出现CPU转速加快，发热等情况]
import java.util.HashM
import java.util.M
import java.util.concurrent.C
import java.util.concurrent.ExecutionE
import java.util.concurrent.ExecutorS
import java.util.concurrent.E
public class HashMapDeadLock implements Callable&Integer& {
private static ExecutorService threadPool = Executors.newFixedThreadPool(10);
private static Map&Integer, Integer& results = new HashMap&&();
public 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 {
for (int i = 0; i & 2000; i++) {
HashMapDeadLock hashMapDeadLock
= new HashMapDeadLock();
threadPool.submit(hashMapDeadLock);
} catch (Exception e) {
e.printStackTrace();
} finally {
threadPool.shutdown();
1） 使用jps查看线程可得：
43125 HashMapDeadLock
2）使用jstack导出多线程栈区信息：
jstack -l 43125 & hash.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=0xa000 nid=0x5d07 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"DestroyJavaVM" prio=5 tid=0x6800 nid=0x1903 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"pool-1-thread-10" prio=5 tid=0xa000 nid=0x6903 runnable [0xcd19000]
java.lang.Thread.State: RUNNABLE
at 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:
- &0xaaba84c8& (a java.util.concurrent.ThreadPoolExecutor$Worker)
"Service Thread" daemon prio=5 tid=0x9800 nid=0x5303 runnable [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"C2 CompilerThread1" daemon prio=5 tid=0x2000 nid=0x5103 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"C2 CompilerThread0" daemon prio=5 tid=0x0000 nid=0x4f03 waiting on condition [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"Signal Dispatcher" daemon prio=5 tid=0xc800 nid=0x4d03 runnable [0x0000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
"Finalizer" daemon prio=5 tid=0x6800 nid=0x3903 in Object.wait() [0xbc58000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on &0xaaa85608& (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked &0xaaa85608& (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:
"Reference Handler" daemon prio=5 tid=0xa800 nid=0x3703 in Object.wait() [0xbb55000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on &0xaaa85190& (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 &0xaaa85190& (a java.lang.ref.Reference$Lock)
Locked ownable synchronizers:
"VM Thread" prio=5 tid=0x8800 nid=0x3503 runnable
"GC task thread#0 (ParallelGC)" prio=5 tid=0xd800 nid=0x2503 runnable
"GC task thread#1 (ParallelGC)" prio=5 tid=0xe000 nid=0x2703 runnable
"GC task thread#2 (ParallelGC)" prio=5 tid=0x1000 nid=0x2903 runnable
"GC task thread#3 (ParallelGC)" prio=5 tid=0x2000 nid=0x2b03 runnable
"GC task thread#4 (ParallelGC)" prio=5 tid=0x2800 nid=0x2d03 runnable
"GC task thread#5 (ParallelGC)" prio=5 tid=0x3000 nid=0x2f03 runnable
"GC task thread#6 (ParallelGC)" prio=5 tid=0x3800 nid=0x3103 runnable
"GC task thread#7 (ParallelGC)" prio=5 tid=0x4800 nid=0x3303 runnable
"VM Periodic Task Thread" prio=5 tid=0x4800 nid=0x5503 waiting on condition
JNI global references: 134
4）从上边部分可看出，代码中的30行出问题了，即往hashmap中写入数据出问题了：
results.put(i, i);
很快就明白因为Hashmap不是线程安全的，所以问题就出在这个地方，我们可以使用线程安全的map即
ConcurrentHashMap后者HashTable来解决该问题：
import java.util.M
import java.util.concurrent.C
import java.util.concurrent.ConcurrentHashM
import java.util.concurrent.ExecutionE
import java.util.concurrent.ExecutorS
import java.util.concurrent.E
public class HashMapDead2LiveLock implements Callable&Integer& {
private static ExecutorService threadPool = Executors.newFixedThreadPool(10);
private static Map&Integer, Integer& results = new ConcurrentHashMap&&();
public 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 {
for (int i = 0; i & 2000; i++) {
HashMapDead2LiveLock hashMapDeadLock
= new HashMapDead2LiveLock();
threadPool.submit(hashMapDeadLock);
} catch (Exception e) {
e.printStackTrace();
} finally {
threadPool.shutdown();
改成ConcurrentHashMap后，重新执行该程序，你会发现很快该程序就执行完了。
浏览: 25559 次
来自: 四川
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'}