jstack

故障描述 Web服务启动之后，服务器CPU使用率瞬间飙升到90%。此时接口服务频繁超时。 故障处理 由于短时间无法定位和修复问题，以免影响终端用户操作体验，采取了回滚操作。 故障问题分析 一般一个应用CPU使用率很高，通常都是由于程序中的死循环引起的。 故障问题定位过程 ####1、使用 top 命令查看占用 CPU 较高的进程 可以看到 PID 为 26484 这个进程的 CPU 占用率最高。 ####2、定位具体进程 使用 'ps aux | grep 26484' 或 'ps -ef | grep 26484' 命令，定位到具体的进程 ####3、查看进程下的线程 CPU 占用情况 使用 'ps -mp 26484 -o THREAD,tid,time | sort -rn' 命令打印出该进程下的线程占用 CPU 情况 可以看到 TID 为 26762 的这个线程占用 CPU 最高 ####4、线程 ID 转换为 16 进制格式 使用 'printf "%x\n" 26762' 命令将线程 ID 转换为 16 进制格式, 以方便下一步查询线程堆栈信息 ####5、查看线程堆栈信息 使用 'jstack 26484 |grep 688a -A 30' 命令打印出高 CPU 占用的线程 26762 的堆栈信息, 如下： 从上面的输出结果就可以定位到具体出问题的代码,

现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention） Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。 A、 jps(Java Virtual Machine Process Status Tool) jps主要用来输出JVM中运行的进程状态信息。语法格式如下： jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： -q 不输出类名、Jar名和传入main方法的参数 -m 输出传入main方法的参数 -l 输出main类或Jar的全限名 -v 输出传入JVM的参数 比如下面： root@ubuntu:/# jps -m -l 2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5

现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention） Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。 A、 jps(Java Virtual Machine Process Status Tool) jps主要用来输出JVM中运行的进程状态信息。语法格式如下： 1 jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： 1 -q 不输出类名、Jar名和传入main方法的参数 2 -m 输出传入main方法的参数 3 -l 输出main类或Jar的全限名 4 - v 输出传入JVM的参数 比如下面： 1 root @ubuntu :/ # jps -m -l 2 2458 org.artifactory.standalone.main.Main /usr/ local

I am trying to do a forced java thread dump programmatically, just like the command jstack -F -l <PID> would do it. My best attempt: I created a subclass from sun.jvm.hotspot.tools.JStack overwriting run() with the following code analogous to sun.jvm.hotspot.tools.JStack.run() but in the last line calling start(printstream) instead of start() : StackTrace stacktrace = new StackTrace(mixedMode, concurrentLocks); try { Class<?> stacktraceTool = stacktrace.getClass().getSuperclass(); Method stacktraceSetAgent = stacktraceTool.getDeclaredMethod("setAgent", new Class<?>[] { BugSpotAgent.class });

Part0 遇到了故障怎么办？ 在生产上，我们会遇到各种各样的故障，遇到了故障怎么办？ 不要慌，只有冷静才是解决故障的利器。 下面以一个例子为例，在生产中碰到了CPU 100%的问题怎么办？ 在生产中真的碰到了CPU 100%的问题，再来看这篇文章已经迟了，还是先来模拟演练下吧。 怎么模拟演练？ （1）查找资料，选型排查CPU高负载问题的工具。 （2）安装一个高负载程序或手写个高负载应用部署。 （3）安装、执行分析工具，实战分析，找出故障原因。 （4）思考与总结。 Part1 工具选型 因为现在大部分的企业应用都是java编写的，所以我们本次排查的高负载应用也是针对java的，但是思路其实是相同的，如果也有php、python、go等语言写的程序，无非就是换个工具而已，排查的步骤都是类似的。 而top这个命令一定是Linux上不可动摇的资源监控工具。 以下三类工具从原生的top、jstack到功能强大的Arthas和一键式查找的show-busy-java-threads，它们都各有长处。在合适的环境选择合适的工具才是考验一个IT人员能力的时候。 运用之道，存乎一心。 1.1 原生方法 此方法无需额外安装工具，在没法连接互联网的情况下使用此方法排查效果较好。 top、printf都是Linux原生命令，jstack、jstat是jdk自带命令工具。

I have a java process loading a lot of data from a bunch of .csv files into a Neo4j database using the BatchInserter . I was using: OpenJDK 7 Ubuntu 12.04 Neo4j 2.0 M3 After loading the first 164 GB (according to ls -lh ) the folder size stopped increasing but the process kept running, no memory was released, and CPU was still at 100% (all according to htop ). The loading process is single threaded, only the JVM is using more than 1 thread - I guess by the ParallelGC . I'm not sure how to diagnose this type of problem but was instructed to try jstack , so have included its output below. Anyone

一、jstack命令 jstack Dump 日志文件中的线程状态 dump 文件里，值得关注的线程状态有： 死锁， Deadlock（重点关注） 执行中， Runnable 等待资源， Waiting on condition（重点关注） 等待获取监视器， Waiting on monitor entry（重点关注） 暂停， Suspended 对象等待中， Object.wait() 或 TIMED_WAITING 阻塞， Blocked（重点关注） 停止， Parked 下面我们先从第一个例子开始分析，然后再列出不同线程状态的含义以及注意事项，最后再补充两个实例。 综合示范一： Waiting to lock 和 Blocked 实例如下： "RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [ 0x00007fd4f8684000 ] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.log4j.Category.callAppenders(Category.java:201) - waiting to lock

原文内容来自于LZ（楼主）的印象笔记，如出现排版异常或图片丢失等问题，可查看当前链接： https://app.yinxiang.com/shard/s17/nl/19391737/2fee7b91-fc6e-4e96-838a-b6926b422368 线上服务器CPU彪高的调试方式 1. 使用TOP获取对应的CPU彪高的进程ID 2. top -p 8948 -H 查看8948进程所对应的所有线程，查看引起CPU彪高的线程PID，此处为9037 3. jstack 8948 >/home/xiaoi/8948thread1.txt 打印当前的线程堆栈信息至txt文件当中（尽可能的将2,3步骤同时进行，否则可能出现top所查看得到的线程ID，在导出堆栈信息时已经不再引起CPU彪高了） 4.将所得到的线程PID转换为16进制，如此处的9037转换为16进制后的结果为234d（堆栈信息中存储的是16进制的线程ID，而我们在通过TOP获取到的线程ID为10进制的ID，故需要做一下转换操作） 5.得到对应的转换为16进制后的线程ID为 234d，此时使用vim 查看对应的8948thread1.txt堆栈文件，直接搜索 ?234d 查看对应的234d线程的堆栈信息，发现线程是持续的 RUNNABLE运行状态，查看异常可知是代码底层所调用的谷歌文本对比插件所引起的死循环导致 使用