hbase jstack工具分析

在分析线上问题时常使用到jstack <PID>命令将当时Java应用程序的线程堆栈dump出来。
面对jstack 日志,我们如何查看?

首先要清楚线程的状态
线程的状态有: new、runnable、running、waiting、timed_waiting、blocked、dead
线程状态变迁图:

各状态说明:
New : 当线程对象创建时存在的状态,此时线程不可能执行;
Runnable :当调用thread.start()后,线程变成为Runnable状态。只要得到CPU,就可以执行;
Running :线程正在执行;
Waiting :执行thread.join()或在锁对象调用obj.wait()等情况就会进该状态,表明线程正处于等待某个资源或条件发生来唤醒自己;
Timed_Waiting :执行Thread.sleep(long)、thread.join(long)或obj.wait(long)等就会进该状态,与Waiting的区别在于Timed_Waiting的等待有时间限制;
Blocked :如果进入同步方法或同步代码块,没有获取到锁,则会进入该状态;
Dead :线程执行完毕,或者抛出了未捕获的异常之后,会进入dead状态,表示该线程结束
其次,对于jstack日志,我们要着重关注如下关键信息
Deadlock :表示有死锁
Waiting on condition :等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析,比如线程正在sleep,网络读写繁忙而等待
Blocked :阻塞
Waiting on monitor entry :在等待获取锁
in Object.wait() :获取锁后又执行obj.wait()放弃锁
对于 Waiting on monitor entry     in Object.wait()的详细描述 :Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。从下图中可以看出,每个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 "Active Thread",而其它线程都是 "Waiting Thread",分别在两个队列 " Entry Set"和 "Wait Set"里面等候。在 "Entry Set"中等待的线程状态是 "Waiting for monitor entry",而在 "Wait Set"中等待的线程状态是 "in Object.wait()"



1) blocked 的例子

程序先输出main,在输出thread,说明mian的线程是先获得同步锁的
执行jstack pid输出信息如下:


可以看到thread1在进行等待获取到锁,此时进入waiting for monitor entry,并是阻塞状态。

而main线程提前获取到锁,当由于调用了sleep此时进入到Timed_waiting状态,此时man线程锁住的对象地址是7f3167cf0,而thread1正在等待获取这个锁对象。

prio:线程的优先级
tid:线程id
nid: 操作系统映射的线程id, 非常关键,后面再使用jstack时补充
1103e9000
106692000 :表示线程栈的起始地址。


从jstack日志中,可以看到:主线程获取到thread2对象上的锁,因此正在执行sleep操作,状态为TIMED_WAINTING, 而thread2由于未获取到thread2对象上的锁,因此处于BLOCKED状态。
再细看,thread2 正在"waiting to lock <7f3167cf0 >",即试图在地址为7f3167cf0 所在的对象获取锁,而该锁却被main线程占有(locked <7f3167cf0 >)。main线程正在"waiting on condition",说明正在等待某个条件触发,由jstacktrace来看,此线程正在sleep。
经验: 如果在jstack日志发现大量的线程在waiting to lock 某个地址,只要能查到哪个线程获取到锁就可以方便定位问题了


2) object.wait();

public static void main(String[] args) {
final Thread thread = new Thread() {
@Override
public void run() {
synchronized (this) {
System.out.println(Thread.currentThread().getName());
try {
wait();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
};
thread.start();
thread.setName("zouxh");//起名字,方便在线程栈里面进行查看
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
synchronized (thread) {
System.out.println(Thread.currentThread().getName());
try {
TimeUnit.SECONDS.sleep(30);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
thread.notify();
}
}
执行后,查看jstack的日志如下:
"zouxh" prio=5 tid=7fe18c97b800 nid=0x115e58000 in Object.wait() [115e57000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7f3112fe8> (a jstat.MainWati$1)
at java.lang.Object.wait(Object.java:485)
at jstat.MainWati$1.run(MainWati.java:16)
- locked <7f3112fe8> (a jstat.MainWati$1)


"main" prio=5 tid=7fe18c000800 nid=0x10c47b000 waiting on condition [10c47a000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:300)
at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:328)
at jstat.MainWati.main(MainWati.java:37)
- locked <7f3112fe8> (a jstat.MainWati$1)

可以看到由于调用了object.wait()方法的时候放弃了锁,所以zouxh这个线程就出现了object.wait()状态,线程的状态就是waiting,等待notify来进行唤醒。


由于mian线程在获得zouxh的线程锁后,调用了sleep方法,所以此时进入了wating on condition等待某一个资源,进入到time_waiting状态。


3) waiting on conditon
private static BlockingQueue<String> blockingQueue = new ArrayBlockingQueue<String>(1);
public static void main(String[] args) {
blockingQueue.add("zouxh");
try {
//阻塞的添加
blockingQueue.put("ssss");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
线程栈如下:
"main" prio=5 tid=7f8f65000800 nid=0x10d7bb000 waiting on condition [10d7ba000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <7f3110d80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:257)
at jstat.WatingTest.main(WatingTest.java:13)


此时main线程进入了waiting on conditon状态,等待某一个资源,此时可以看到是在
a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObjec进行了等待,阻塞住了,这是由于put发生了阻塞。


总结

对于jstack日志,我们要着重关注如下关键信息
Deadlock :表示有死锁
Waiting on condition :等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析,比如线程正在sleep,网络读写繁忙而等待
Blocked :阻塞
Waiting on monitor entry :在等待获取锁

如果说系统慢,那么要特别关注 Blocked,Waiting on condition
如果说系统的cpu耗的高,那么肯定是线程执行有死循环,那么此时要关注下Runable状态。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
jstack生成的Thread Dump日志.docx 系统线程状态 (Native Thread Status) 系统线程有如下状态: deadlock 死锁线程,一般指多个线程调用期间进入了相互资源占用,导致一直等待无法释放的情况。 runnable 一般指该线程正在执行状态中,该线程占用了资源,正在处理某个操作,如通过SQL语句查询数据库、对某个文件进行写入等。 blocked 线程正处于阻塞状态,指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程。 waiting on condition 线程正处于等待资源或等待某个条件的发生,具体的原因需要结合下面堆栈信息进行分析。 (1)如果堆栈信息明确是应用代码,则证明该线程正在等待资源,一般是大量读取某种资源且该资源采用了资源锁的情况下,线程进入等待状态,等待资源的读取,或者正在等待其他线程的执行等。 (2)如果发现有大量的线程都正处于这种状态,并且堆栈信息中得知正等待网络读写,这是因为网络阻塞导致线程无法执行,很有可能是一个网络瓶颈的征兆: 网络非常繁忙,几乎消耗了所有的带宽,仍然有大量数据等待网络读写; 网络可能是空闲的,但由于路由或防火墙等原因,导致包无法正常到达; 所以一定要结合系统的一些性能观察工具进行综合分析,比如netstat统计单位时间的发送包的数量,看是否很明显超过了所在网络带宽的限制;观察CPU的利用率,看系统态的CPU时间是否明显大于用户态的CPU时间。这些都指向由于网络带宽所限导致的网络瓶颈。 (3)还有一种常见的情况是该线程在 sleep,等待 sleep 的时间到了,将被唤醒。 waiting for monitor entry 或 in Object.wait() Moniter 是Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者class的锁,每个对象都有,也仅有一个 Monitor。 从上图可以看出,每个Monitor在某个时刻只能被一个线程拥有,该线程就是 "Active Thread",而其他线程都是 "Waiting Thread",分别在两个队列 "Entry Set"和"Waint Set"里面等待。其中在 "Entry Set" 中等待的线程状态是 waiting for monitor entry,在 "Wait Set" 中等待的线程状态是 in Object.wait()。 (1)"Entry Set"里面的线程。 我们称被 synchronized 保护起来的代码段为临界区,对应的代码如下: synchronized(obj){} 当一个线程申请进入临界区时,它就进入了 "Entry Set" 队列中,这时候有两种可能性: 该Monitor不被其他线程拥有,"Entry Set"里面也没有其他等待的线程。本线程即成为相应类或者对象的Monitor的Owner,执行临界区里面的代码;此时在Thread Dump中显示线程处于 "Runnable" 状态。 该Monitor被其他线程拥有,本线程在 "Entry Set" 队列中等待。此时在Thread Dump中显示线程处于 "waiting for monity entry" 状态。 临界区的设置是为了保证其内部的代码执行的原子性和完整性,但因为临界区在任何时间只允许线程串行通过,这和我们使用多线程的初衷是相反的。如果在多线程程序中大量使用synchronized,或者不适当的使用它,会造成大量线程在临界区的入口等待,造成系统的性能大幅下降。如果在Thread Dump中发现这个情况,应该审视源码并对其进行改进。 (2)"Wait Set"里面的线程 当线程获得了Monitor,进入了临界区之后,如果发现线程继续运行的条件没有满足,它则调用对象(通常是被synchronized的对象)的wait()方法,放弃Monitor,进入 "Wait Set"队列。只有当别的线程在该对象上调用了 notify()或者notifyAll()方法,"Wait Set"队列中的线程才得到机会去竞争,但是只有一个线程获得对象的Monitor,恢复到运行态。"Wait Set"中的线程在Thread Dump中显示的状态为 in Object.wait()。通常来说, 通常来说,当CPU很忙的时候关注 Runnable 状态的线程,反之则关注 waiting for monitor entry 状态的线程。 JVM线程运行状态 (JVM Thread Status)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值