关于java8jstack的信息

本篇文章给大家谈谈java8jstack，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、电脑Java8update内存使用率高
• 2、JDK命令介绍
• 3、怎样使用jstack诊断Java应用程序故障

电脑Java8update内存使用率高

可能是代码原因导致的问题，也可能是其他原因导致的问题。

使用dstat和top查看内存使用最高的应用，查到内存占用最高的是java应用，使用2253M内存，但是这台服务器跑了好几个java，具体哪个进程使用top看下资源情况，使用top，使用dstat可以看到java应用整体内存使用率超过了70%，其中pid为16494的进程一个应用占了28.7的内存，使用ps查看16494的线程情况，命令：psp16494-L-opcpu,pmem,pid,tid,time,tname,cmd，看到16494这个pid的应用产生了很多线程。在分析前需要将17417这个id转换为16进制，方便查找信息12[root@localhost~]#printf"%x\n"17417，440916进制为4409。将pid为16494的应用打印到日志中1[root@localhost~]#jstack-l16494jstack.log。查看内存堆栈信息，1[root@localhost~]#vimjstack.log，[root@localhost~]#vimjstack.log在日志信息中查找刚刚转换的4409。可以看到这个线程状态为WAITING通过查看日志发现有大量的waitingoncondition。1，parkingtowaitfor存在大量线程等待被唤醒，占用大量内存。

JDK命令介绍

命令jps用于列出java进程，直接运行jps不加任何参数，可以列出Java程序的进程ID以及Main函数等名称。

参数-q指定jps只输出进程ID，而不输出类的短名称

参数-m用于输出传递给Java进程（主函数）的参数

参数 -l用于输出主函数的完整路径

参数 -v可以显示传递给JVM的参数

jstat是一个可以用于观察Java应用程序运行时信息的工具。它的功能非常强大，可以通过它，查看堆信息的详细使用情况。主要用于监控虚拟机的各种运行状态信息，如类的装载、内存、垃圾回收、JIT编译器等，在没有GUI的服务器上，这款工具是首选的一款监控工具。

基本使用语法为：

选项option可以由以下值构成：

-class：显示ClassLoader的相关信息。

-compiler：显示JIT编译的相关信息。

-gc：显示与GC相关的堆信息。

-gccapacity：显示各个代的容量及使用情况。

-gccause：显示垃圾收集相关信息（同-gcutil），同时显示最后一次或当前正在发生的垃圾收集的诱发原因。

-gcnew：显示新生代信息。

-gcnewcapacity：显示新生代大小与使用情况。

-gcold：显示老年代与永久代的信息。

-gcoldcapacity：显示老年代的大小。

-gcmetacapacity：显示元空间的大小。（在java8之前是使用-gcpermcapacity显示永久代的大小）

-gcutil：显示垃圾收集信息。

-printcompilation：输出JIT编译的方法信息。

以上选项可以输入 jstat -options 查看。

-t 参数可以在输出信息前加一个 Timestamp 列，显示程序的运行时间。

-h 参数可以在周期性数据输出时，输出多少行数据后，跟着输出一个表头信息。

vmid 参数就是Java进程id。

interval 参数用于指定输出统计数据的周期，单位为毫秒。

count 用于指定一共输出多少次数据。

jinfo 可以用来查看正在运行的Java运行程序的扩展参数，甚至支持在运行时修改部分参数。可以用来查看正在运行的 java 应用程序的扩展参数，包括Java System属性和JVM命令行参数；也可以动态的修改正在运行的 JVM 一些参数。当系统崩溃时，jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息。

jmap 可以生成Java应用程序的堆快照和对象的统计信息。基本语法为：

option 选项如下：

-dump 生成java堆转储快照。格式为： -dump:[live,]format=b,file=,其中live子参数说明是否只dump出存活的对象

-finalizerinfo 显示在F-Queue中等待Finalizer线程执行finalize方法的对象。只在Linux/Solaris平台下有效

-heap 显示java堆详细信息，如使用哪种收集器、参数配置、分代情况等，在Linux/Solaris平台下有效

-histo 显示堆中对象统计信息，包含类、实例对象、合集容量

-permstat 以ClassLoader为统计口径显示永久代内存状态。只在Linux/Solaris平台下有效

-F 当虚拟机进程对-dump选项没有相应时。可使用这个选项强制生成dump快照。只在Linux/Solaris平台下有效

使用 jhat 工具可以用于分析Java应用程序的堆快照内容。jhat 在分析完成后，使用HTTP服务器展示其分析结果。在浏览器中访问

jstack 可用于导出Java应用程序的线程堆栈。语法为：

-l选项用于打印锁的附加信息。

jstack 工具会在控制台输出程序中所有的锁信息，可以使用重定向将输出保存到文件。

通过 jstack 工具不仅可以得到线程堆栈，它还能自动进行死锁检查，输出找到的死锁信息。

之前所述的工具中，只涉及到监控本机的Java应用程序。而在这些工具中，一些监控工具也支持对远程计算机的监控（如：jps、jstat）。为了启用远程监控，则需要配合使用jstatd工具。

命令jstatd是一个RMI服务端程序，它的作用相当于代理服务器，建立本地计算机与远程监控工具的通信。jstatd服务器将本机的Java应用程序信息传递到远程计算机。

JConsole（Java Monitoring and ManagementConsole）工具时JDK自带的图形化性能监控工具。通过JConsole工具，可以查看Java应用程序的运行概况，监控堆信息、永久区使用情况、类加载情况等。

怎样使用jstack诊断Java应用程序故障

如果单靠通过查看代码是很难去发现这个问题,在这一次故障排查中,我也学到了怎样更好的使用jvm监控工具来进行诊断,主要用到了jstack和jmap命令,jmap上次已经讲过就不再讲了,下面就一个例子来讲怎么使用jstack来对的Java程序进行诊断。

首先让我们来了解一下jstack这个命令的作用,jstack 是一个可以返回在应用程序上运行的各种各样线程的一个完整转储的实用程序,您可以使用它查明问题。jstack [-l] pid,jpid可以通过使用jps命令来查看当前Java程序的jpid值,-l是可选参数,它可以显示线程阻塞/死锁情况。

/**

* 死锁例子

* @author crane.ding

* @since 2011-3-20

*/

public class DeadLock {

public static void main(String[] args) {

final Object obj_1 = new Object(), obj_2 = new Object();

Thread t1 = new Thread("t1"){

@Override

public void run() {

synchronized (obj_1) {

try {

Thread.sleep(3000);

} catch (InterruptedException e) {}

synchronized (obj_2) {

System.out.println("thread t1 done.");

}

}

}

};

Thread t2 = new Thread("t2"){

@Override

public void run() {

synchronized (obj_2) {

try {

Thread.sleep(3000);

} catch (InterruptedException e) {}

synchronized (obj_1) {

System.out.println("thread t2 done.");

}

}

}

};

t1.start();

t2.start();

}

}

以上DeadLock类是一个死锁的例子,假使在我们不知情的情况下,运行DeadLock后,发现等了N久都没有在屏幕打印线程完成信息。这个时候我们就可以使用jps查看该程序的jpid值和使用jstack来生产堆栈结果问题。

$ java -cp deadlock.jar DeadLock

$

$ jps

3076 Jps

448 DeadLock

$ jstack -l 448 deadlock.jstack

结果文件deadlock.jstack内容如下：

2011-03-20 23:05:20

Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode, sharing):

"DestroyJavaVM" prio=6 tid=0x00316800 nid=0x9fc waiting on condition [0x00000000]

java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

- None

"t2" prio=6 tid=0x02bcf000 nid=0xc70 waiting for monitor entry [0x02f6f000]

java.lang.Thread.State: BLOCKED (on object monitor)

at com.demo.DeadLock$2.run(DeadLock.java:40)

- waiting to lock 0x22a297a8 (a java.lang.Object)

- locked 0x22a297b0 (a java.lang.Object)

Locked ownable synchronizers:

- None

"t1" prio=6 tid=0x02bce400 nid=0xba0 waiting for monitor entry [0x02f1f000]

java.lang.Thread.State: BLOCKED (on object monitor)

at com.demo.DeadLock$1.run(DeadLock.java:25)

- waiting to lock 0x22a297b0 (a java.lang.Object)

- locked 0x22a297a8 (a java.lang.Object)

Locked ownable synchronizers:

- None

"Low Memory Detector" daemon prio=6 tid=0x02bb9400 nid=0xa6c runnable [0x00000000]

java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

- None

"CompilerThread0" daemon prio=10 tid=0x02bb2800 nid=0xcb8 waiting on condition [0x00000000]

java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

- None

"Attach Listener" daemon prio=10 tid=0x02bb1000 nid=0x7f4 waiting on condition [0x00000000]

java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

- None

"Signal Dispatcher" daemon prio=10 tid=0x02bd2800 nid=0xd80 runnable [0x00000000]

java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

- None

"Finalizer" daemon prio=8 tid=0x02bab000 nid=0xe1c in Object.wait() [0x02d3f000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on 0x229e1148 (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)

- locked 0x229e1148 (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

Locked ownable synchronizers:

- None

"Reference Handler" daemon prio=10 tid=0x02ba6800 nid=0xbe0 in Object.wait() [0x02cef000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on 0x229e1048 (a java.lang.ref.Reference$Lock)

at java.lang.Object.wait(Object.java:485)

at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)

- locked 0x229e1048 (a java.lang.ref.Reference$Lock)

Locked ownable synchronizers:

- None

"VM Thread" prio=10 tid=0x02b6a400 nid=0x568 runnable

"VM Periodic Task Thread" prio=10 tid=0x02bc8400 nid=0x75c waiting on condition

JNI global references: 878

Found one Java-level deadlock:

=============================

"t2":

waiting to lock monitor 0x02baaeec (object 0x22a297a8, a java.lang.Object),

which is held by "t1"

"t1":

waiting to lock monitor 0x02baa2bc (object 0x22a297b0, a java.lang.Object),

which is held by "t2"

Java stack information for the threads listed above:

===================================================

"t2":

at com.demo.DeadLock$2.run(DeadLock.java:40)

- waiting to lock 0x22a297a8 (a java.lang.Object)

- locked 0x22a297b0 (a java.lang.Object)

"t1":

at com.demo.DeadLock$1.run(DeadLock.java:25)

- waiting to lock 0x22a297b0 (a java.lang.Object)

- locked 0x22a297a8 (a java.lang.Object)

Found 1 deadlock.

从这个结果文件我们一看到发现了一个死锁,具体是线程t2在等待线程t1,而线程t1在等待线程t2造成的,同时也记录了线程的堆栈和代码行数,通过这个堆栈和行数我们就可以去检查对应的代码块,从而发现问题和解决问题。

关于java8jstack和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。