java打印堆栈
❶ android 怎么打印函数堆栈 java
C++也是支持异常处理的，异常处理库中，已经包含了获取backtrace的接口，Android也是利用这个接口来打印堆栈信息的。在Android的C++中，已经集成了一个工具类CallStack，在libutils.so中。
使用方法：
[cpp]viewplain
#include<utils/CallStack.h>
...
CallStackstack;
stack.update();
stack.mp();
使用方式比较简单。目前Andoid4.2版本已经将相关信息解析的很到位，符号表查找，demangle，偏移位置校正都做好了。
❷ 如何用Jstack把java进程中的堆栈信息输出到
1.2 Thread Dump特点
1. 能在各种操作系统下使用
2. 能在各种Java应用服务器下使用
3. 可以在生产环境下使用而不影响系统的性能
4. 可以将问题直接定位到应用程序的代码行上
1.3 Thread Dump 能诊断的问题
1. 查找内存泄露，常见的是程序里load大量的数据到缓存；
2. 发现死锁线程；
1.4如何抓取Thread Dump
一般当服务器挂起,崩溃或者性能底下时,就需要抓取服务器的线程堆栈(Thread Dump)用于后续的分析. 在实际运行中，往往一次 mp的信息，还不足以确认问题。为了反映线程状态的动态变化，需要接连多次做threadmp，每次间隔10-20s，建议至少产生三次 mp信息，如果每次 mp都指向同一个问题，我们才确定问题的典型性。
有很多方式可用于获取ThreadDump, 下面列出一部分获取方式：
操作系统命令获取ThreadDump:
Windows:
1.转向服务器的标准输出窗口并按下Control + Break组合键, 之后需要将线程堆栈复制到文件中；
UNIX/ linux：
首先查找到服务器的进程号(process id), 然后获取线程堆栈.
1. ps –ef | grep java
2. kill -3 <pid>
注意：一定要谨慎, 一步不慎就可能让服务器进程被杀死。kill -9 命令会杀死进程。
❸ Java 异常中什么是显示堆栈轨迹
//方法出异常时会指明在那一行，显示异常的堆栈轨迹
try {
String s[]={"1"};
s[1]="abc";
} catch (Exception e) {
e.printStackTrace();
}
//
e.printStackTrace();
就是打印出异常堆栈信息，你也可以不调用此条语句。如：
try {
String s[]={"1"};
s[1]="abc";
} catch (Exception e) {
System.out.print("出错了"); }
❹ 原来jdk自带了这么好玩的工具——使用 jstack定位死循环
线程快照是java虚拟机内每一个线程正在执行的方法堆栈的集合，生成线程快照的主要目的是用于定位线程出现问题的位置；常见的问题有
命令格式
jstack的option参数并不多，真正用到的也就三个，接下来我们一个个介绍一下
- -F ：当线程挂起(Suspended)时，使用jstack -l pid命令是不会打印堆栈信息的，使用-F则可以强制输出线程堆栈；但是会停止但
- -l ：打印的信息除了堆栈外，还会显示锁芹梁返的附加信息；
- -m ：同时输出java和C/C++的堆栈信息；在java的系统类库里面，有很多方法都是native修饰的，这些native修饰的方法你在java层面是看不到源码的，因为这些方法都是C/C++实现嫌饥的；
在线程的堆栈中，需要特别留意以下几种状态：
不带option参数的命令
打印结果如下
第一行各个单词的解析，
这里我们使用2个窗口，分别使用以下2个命令来测试
通过2个窗口对比可以看到，加了-l的命令多打印了锁的信息；
一般情况下，如果程序出错了， 都不会直接在生产环境的服务器上找错误，这个时候就可以用到一个非常实用的功能，将堆栈快照导出来，然后到别的电脑上看，命令如下
执行后，就可以看到文件已经导出来了
通过cat命令可以看到，里面的内容和我们在命令行输出的内容是一样的
首先我们准备好一个死循环的线程，在线程内定一个while的死循环，并且给这个线程起个名字为：yexindogn，阿里巴巴的开发规范里面有一个规定，就是每个线程必须起一个名字，起名字就是为了 以后程序出问题的时候好找错误；
接着我们将此代码打成jar包扔到linux服务器上运行，直接输入 java -jar Test.jar 命令即可运行，运行后我们可以看到控制台一直在输出112这个字符，这就代表程序已经在运行了；
接着在看下CPU的运行情况，使用top命令查看cpu占用情况，排在第一位的是进程号为30328的进程，占用了6.6%的cpu； 这边我使用了2个命令行连到同一台服务器，一个窗口用来运行刚刚的jar包，另一个窗口用来查找错误；
知道进程号了，接着就是找线程了，输入以下命令
打印结果如下，这里有一点需要注意，在我们加上-Hp指令后，PID展示就是线程的id了，这时候我们看到占用CPU最高的线程id是30365；
还有另一种方式，就是使用ps命令来查找线程
通过这个命令我们可以看到这边占用最高的线程id也是30365 ;
以上的方式我们成功找到了占用cpu高的线程id是30365，但这个id是十进制的，在这里需要先转为16进制，输入命令
计算出对应的16进制为：769d
当然也可以用其他的计算工具，比如mac系统自带计算器就支持进制之间的转换
在命令行输入以下命令，这种方法更加快速，推荐使用
其中，grep 命令是查找结果为769d的内容，-A 20 表示打印匹配所在行的后20行内容。直接帮我们定位到所在线程的堆栈，结果如下
当然也可以用下面的死办法，先打印出所有的堆栈快照；
打印结果如下
接着我用刚刚计算出来的16进制复制出来在这里搜索一下，经过查看就知道是我们刚刚起了名字为yexindong的线程出错了，出错的位置在Test.java的第13行代码
我们看看java代码，确实是第13行这里的死循环导致的
首先打开任务管理器，因为默认windows的任务管理器是不显示进程pid的，所以我们需要设置一下，选择 查看 选择列(S)...
选中PID进程表示符后点击确定按钮
然后我们就可以看到占用CPU最高的java进程PID为：976
因为windows不能直接查看java进程中的线程信息，所以我们需要借助一个工具，渣指这个工具是微软自己开发的，叫做Process Explorer ，网上很多，需要的童鞋请自行网络，打开后找到pid为976的进程右击选择 属性
在弹出的窗口中找到线程这一栏，它的排序默认就是按照cpu占用的率倒序排列的，所以最上面的就是占用cpu最高的线程了，记住它的线程id：3548
刚刚拿到的进程id是十进制的，但是我们导出的jstack信息里面，线程id是以16进制来展示的，所以我们要先将这个线程id为3548转为16进制的，使用windows自带的计算器即可，在快捷命令行输入calc
计算器打开后将其设置为程序员使用的计算器
接着输入线程id3548，在按一下16进制，就会自动进行转换，结果为ddc，记住这个16进制；
在命令行输入以下指令导出进程的堆栈快照信息
几秒钟后，快照导出了，静静地躺在文件夹里，等待着我们打开
用Notepad++打开导出的文件，搜索刚刚计算出来的16进制ddc，就可以定位到线程出错的位置了
有些童鞋可能会觉得用这个jstack命令麻烦了，那java在代码里面可不可以打印出堆栈呢？你别说，还真有，就是这个方法：Thread.getAllStackTraces()；光说不练假把式，来个demo测试一下吧
执行后打印结果如下，由此可以看到，将当前进程的所有线程都打印出来了，但是这边只打印了简单的堆栈信息，对于开发人员来说，已经起到了监控作用；
作为调优和找错的工具来说，可以说jstack是用的最多的一个工具了，但是由于局限性，现在已经慢慢被替换掉了；大家更倾向于使用阿里巴巴开发的工具arthas；感兴趣的童鞋可以了解下！
❺ slf4j怎么打印java错误堆栈信息throwable对象
SLF4J 1.6.0以前的版本，如果打印异常堆栈信息，必雹和须用
log.error(Stringmsg,Throwablet)
log.info等对应方法．
如果msg含有变量，一般用String.format方法格式化msg.
如果用
error(Stringformat,Object...arguments)
等其它方法，异常堆栈信息会丢失．
幸好，SLF4J 1.6.0以后的版本对这个不友此肆团好的异常信息log改进了．
error(Stringformat,Object…arguments)这个方法也会打印异常堆栈信息，只不过规定throwable对象必须为
最后一个参数．如果不遵守这森橘个规定，异常堆栈信息不会log出来．
❻ kill-3生成的线程堆栈怎么查看
第一步：在终端运行Java程序
第二步：通过命令 pidof java 找到已经启动的java进程的ID，选择需要查看的java程序的进程ID
第三步：使用命令 kill -3 <java进行的 pid> 打印出java程序的线程堆栈信息
第四步：通常情况下运行的项目可和卖迅能会比较大，那么这个时候打印的堆栈信息可能会有几千到几万行，为了方便查看，我们往往需要将输出内容进行重定向
使用linux下的重定向命令方式即可：例如： demo.sh > run.log 2>&1 将输出信息重定向到 run.log中。
注：在操作系统中，0 1 2分别对应着不同的含义， 如下：
0 ： 标准输入，即：C中的stdin ， java中的System.in
1 ： 标准输出， 即：C中的stdout ，java中的配正System.out
2 ： 错误输出， 即：C中的stderr ， java中的System.err
Demo：
----------------------------------------------------------------------------------------------
Sources Code ：
public class PrintThreadTrace {
Object obj1 = new Object();
Object obj2 = new Object();
public void func1(){
synchronized (obj1){
func2();
}
}
public void func2(){
synchronized (obj2){
while(true){
System.out.print("");
}
}
}
public static void main(String[] args){
PrintThreadTrace ptt = new PrintThreadTrace();
ptt.func1();
}
}
----------------------------------------------------------------------------------------------------------------
按照步骤操作后唤此的打印输出信息：
Full thread mp Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):
"Service Thread" daemon prio=10 tid=0x00007fdc880a9000 nid=0x12a4 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" daemon prio=10 tid=0x00007fdc880a7000 nid=0x12a3 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" daemon prio=10 tid=0x00007fdc880a4000 nid=0x12a2 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"JDWP Command Reader" daemon prio=10 tid=0x00007fdc50001000 nid=0x1299 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"JDWP Event Helper Thread" daemon prio=10 tid=0x00007fdc880a1800 nid=0x1298 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"JDWP Transport Listener: dt_socket" daemon prio=10 tid=0x00007fdc8809e000 nid=0x1297 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x00007fdc88091000 nid=0x1296 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=10 tid=0x00007fdc88071800 nid=0x1295 in Object.wait() [0x00007fdc77ffe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000ecb04858> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked <0x00000000ecb04858> (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)
"Reference Handler" daemon prio=10 tid=0x00007fdc8806f800 nid=0x1294 in Object.wait() [0x00007fdc7c10b000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000ecb04470> (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 <0x00000000ecb04470> (a java.lang.ref.Reference$Lock)
"main" prio=10 tid=0x00007fdc8800b800 nid=0x128e runnable [0x00007fdc8fef7000]
java.lang.Thread.State: RUNNABLE
at com.wenchain.study.PrintThreadTrace.func2(PrintThreadTrace.java:20)
- locked <0x00000000ecc04b20> (a java.lang.Object)
at com.wenchain.study.PrintThreadTrace.func1(PrintThreadTrace.java:13)
- locked <0x00000000ecc04b10> (a java.lang.Object)
at com.wenchain.study.PrintThreadTrace.main(PrintThreadTrace.java:27)
"VM Thread" prio=10 tid=0x00007fdc8806b000 nid=0x1293 runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007fdc88021000 nid=0x128f runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007fdc88023000 nid=0x1290 runnable
"GC task thread#2 (ParallelGC)" prio=10 tid=0x00007fdc88024800 nid=0x1291 runnable
"GC task thread#3 (ParallelGC)" prio=10 tid=0x00007fdc88026800 nid=0x1292 runnable
"VM Periodic Task Thread" prio=10 tid=0x00007fdc880b3800 nid=0x12a5 waiting on condition
JNI global references: 1391
Heap
PSYoungGen total 17920K, used 1270K [0x00000000ecb00000, 0x00000000ede80000, 0x0000000100000000)
eden space 15872K, 8% used [0x00000000ecb00000,0x00000000ecc3d898,0x00000000eda80000)
from space 2048K, 0% used [0x00000000edc80000,0x00000000edc80000,0x00000000ede80000)
to space 2048K, 0% used [0x00000000eda80000,0x00000000eda80000,0x00000000edc80000)
ParOldGen total 39424K, used 0K [0x00000000c6200000, 0x00000000c8880000, 0x00000000ecb00000)
object space 39424K, 0% used [0x00000000c6200000,0x00000000c6200000,0x00000000c8880000)
PSPermGen total 21504K, used 2619K [0x00000000c1000000, 0x00000000c2500000, 0x00000000c6200000)
object space 21504K, 12% used [0x00000000c1000000,0x00000000c128edd8,0x00000000c2500000)
----------------------------------------------------------------------------------------------------------------------------
上面的信息中包含了当前JVM中所有运行的线程信息，其中在示例中我们启动的线程为main线程，其余的都是JVM自己创建的。
在打印的信息中，我们可以清楚的看见当前线程的调用上下文，可以很清楚的知道程序的运行情况。
并且我们在最后面还能看见当前虚拟机中的内存使用情况，青年世代，老年世代的信息等等...
PS: 在JDK1.5以上，我们可以通过在Java程序中调用Thread.getStackTrace()方法来进行堆栈的自动打印，使得线程堆栈的打印时机可编程控制。
文章知识点与官方知识档案匹配
Java技能树首页概览
89841 人正在系统学习中
点击阅读全文
打开CSDN，阅读体验更佳
jstack-查看Java进程的线程堆栈信息,锁定高消耗资源代码
jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下: jstack[option]pid jstack[option]executable core jstack[option][server-id@]remote-hostname-or-ip 命令行参数选项说明如下: ...
011Java并发包018查看线程堆栈信息_执笔未来的博客
java.util.concurrent.ScheledThreadPoolExecutor$DelayedWorkQueue.take(ScheledThreadPoolExecutor.java:1088) java.util.concurrent.ScheledThreadPoolExecutor$DelayedWorkQueue.take(ScheledThreadPoolExecutor.java:809) java.util.concurre...
最新发布 jstack -- java堆栈常用排查指令
jstack -- java堆栈常用排查指令
继续访问
热门推荐 jstack 命令查看JAVA线程堆栈
JAVA堆栈信息实际生产中，可能由于开发以及测试未能全面覆盖的代码质量、性能问题，而引致线程挂起甚至崩溃。可能就需要查看堆栈信息来排查问题了。jps -lvmjps -lvm 用于查看当前机器上运行的java进程。C:\Users\Administrator>jps -lvm 7348 -Dosgi.requiredJavaVersion=1.8 -Dosgi.instance.area.defa
继续访问
Java多线程——查看线程堆栈信息
Java多线程——查看线程堆栈信息 摘要：本文主要介绍了查看线程堆栈信息的方法。 使用Thread类的getAllStackTraces()方法 方法定义 可以看到getAllStackTraces()方法的返回值是一个Map对象，key是Thread的实例，value是一个StackTraceElement实例数组： 1 public static Map<Thread, S...
继续访问
java堆栈常用排查指令
java 异常排查四板斧 1、查看java 堆栈线程信息 说明 jstack命令打印指定Java进程、核心文件或远程调试服务器的Java线程的Java堆栈跟踪信息。 对于每个Java框架，完整的类名，方法名， 字节码索引(BCI)和行号(如果有的话)被打印出来。 使用-m选项，jstack命令打印程序中所有线程的Java和本机帧 计数器(PC)。 对于每个本机帧，当可用时，将打印离PC最近的本机符号。 c++乱码的名字不会被修改。 要demangle c++名称，输出这个 命令可以管道到c++filt。 当
继续访问
java诊断工具-Arthas（thread命令）查看当前线程堆栈
cpu使用率与linux 命令top -H -p <pid>的线程CPU类似 1、支持一键展示当前最忙的前N个线程并打印堆栈 thread -n 3 没有线程ID，包含[Internal]表示为JVM内部线程，参考dashboard命令的介绍。 cpuUsage为采样间隔时间内线程的CPU使用率，与dashboard命令的数据一致。 deltaTime为采样间隔时间内线程的增量CPU时间，小于1ms时被取整显示为0ms。 time线程运行总CPU...
继续访问
java查看线程的堆栈信息
通过使用jps 命令获取需要监控的进程的pid，然后使用jstackpid 命令查看线程的堆栈信息。 通过jstack命令可以获取当前进程的所有线程信息。 每个线程堆中信息中，都可以查看到线程ID、线程的状态（wait、sleep、running 等状态）、是否持有锁信息等。 jstack -l <pid> >jvm_listlocks.txt 转...
继续访问
java 查看线程堆栈信息_Java多线程——查看线程堆栈信息
java多线程——查看线程堆栈信息摘要：本文主要介绍了查看线程堆栈信息的方法。使用thread类的getallstacktraces()方法方法定义可以看到getallstacktraces()方法的返回值是一个map对象，key是thread的实例，value是一个stacktraceelement实例数组：1 public static map getallstacktraces()使用可以使...
继续访问
java线程堆栈信息分析
java堆栈信息分析
继续访问
java 查看堆栈_javap 命令查看堆栈中信息
javap命令是对.java文件进行反编译，通过这个命令可以看到堆栈中是怎么压栈和出栈的已经执行顺序，这里简单解释下javap的简单的使用，下面举个例子：题目：i++ 和++i的区别解释：简单点说 这个问题都不难回答，这里就不说了，但是实际上堆栈中区别也是老大了(这里就用到了javap命令)， 步骤：1.在任意一个盘下面建一个名为Test.java的文件(文件名可以随意命名)代码如下：public...
继续访问
java 查看线程堆栈信息_jstack-查看Java进程的线程堆栈信息，锁定高消耗资源代码。...
jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：jstack[option]pidjstack[option]executablecorejstack[option][server-id@]remote-hostname-or-ip命令行参数选项说明如下：-llonglistings，会打印出额外的锁信息，在发生死锁时可以用jstack-lpid来观察...
继续访问
java堆栈信息怎么看_线程堆栈信息怎么看？ - cs_person的个人空间 - OSCHINA - 中文开源技术交流社区...
一条线程堆栈信息大概长成下面这个样子：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 m...
继续访问
线程堆栈信息怎么看？
一条线程堆栈信息大概长成下面这个样子： RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd...
继续访问
java的栈和堆
栈与堆都是Java用来在Ram中存放数据的地方。与C++不同，Java自动管理栈和堆，程序员不能直接地设置栈或堆。 Java 的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立，它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的，堆的优势是可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在...
继续访问
查看java线程_【JAVA】Java线程堆栈信息查看
如何获得线程的堆栈信息？线上服务器cpu 100%了，该如何排查问题？1.top命令查询哪个pid进程占用cpu高(ps -ef|grep java 获取PID号)2.通过 top -Hp pid 可以查看该进程下各个线程的cpu使用情况,获取占用cpu高的线程id3.执行命令：printf "%X\n" 线程tid(用于获取占用cpu高的线程id的16进制数)4.执行命令：jstack pid ...
继续访问
kill -3 java_kill -3 PID命令获取java应用堆栈信息
一、应用场景：当linux服务器出现异常情况(响应缓慢，负载持续飙升)并且服务器没有安装对应的包而无法使用jstack等命令时，可以使用linux的kill相关命令打印堆栈信息。命令格式：kill -3 PID二、执行步骤：2.1、获取java进程的PIDps -ef|grep java结果的第二列数字就是进程对应的pid。2.2、kill -3 PID(1)如果项目通过Tomcat进行发布(普通...
继续访问
jstack 工具 查看JVM堆栈信息
1|0介绍 jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或corefile或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使用方式只支持以下的这种方式： jstack [-l] pid 主要分为两个功能： a． 针对活着的进程做本地的或远程的线程mp； b． 针对core文件做线程mp。 jstack用于生成java虚拟机当前时刻的线程快照。线程快照是...
继续访问
linux查看java堆栈
1、查看JAVA进程JVM参数 jinfo -flags pid(进程号) -XX:CICompilerCount=2 最大的并行编译数 -XX:InitialHeapSize=16777216 JVM 的初始堆内存大小 -XX:MaxHeapSize=257949696 JVM 的最大堆内存大小 -XX:MaxNewSize=85983232 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=5570560 -XX:OldSize=11206656 2、JVM 查看.
继续访问
Linux 如何查看一个进程的堆栈
有两种方法：第一种：pstack 进程ID第二种，使用gdb 然后attach 进程ID，然后再使用命令 thread apply all bt 两种方法都可以列出进程所有的线程的当前的调用栈。不过，使用gdb的方法，还可以查看某些信息，例如局部变量，指针等。不过，如果只看调用栈的话，pstack还是很方便的。
继续访问
JAVA获取堆栈信息
1. 通过Throwable获取 StackTraceElement[] stackTrace = new Throwable().getStackTrace(); 2. 通过Thread获取 StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
继续访问
java 查看线程栈大小_基于 Java 线程栈的问题排查
除日志外，还有没有别的方式跟踪线上服务问题呢？或者，跟踪并排除日志里无法发现的问题？方法当然是有的，就是通过现场快照定位并发现问题。我们所说的现场，主要指这两方面：Java 线程栈。线程栈是Java线程工作的快照，可以获得当前线程在做什么；Java 内存堆。堆是JVM的内存快照，可以获取内存分配相关信息。
❼ java jstack
java jstack是什么，让我们一起了解一下？
jstack是java虚拟机自带的一种堆栈跟踪工具，用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，主要分为两个功能：针对活着的进程做本地的或远程的线程mp，以及针对core文件做线程mp。
jstack的概穗码册念是什么？
1、jstack命令的语法格式：jstack
2、Dump文件：Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到mp文件中。Dump文件是用来给驱动程序编写人员调试驱动程序用模禅的，这种文件必须用专门的工具软件打开，比如使用Windbg。
在Windbg中可以通过.mp命令保存进程的mp文件。比如下面的命令把当前进程的镜像保存为c:\testmp.dmp文件：.mp /ma c:\testmp.dmp。
其中、ma参数表示mp文件应该包含进程的完整信息，包括整个用户态的内存，这样mp文件尺寸会比较大，信息非常全面。如果不是用、ma参数，保存下来的mp文件只包含了部分重要资料，比如寄存器和线程栈空间，文件尺寸会比较小，无法分析所有的数据。
3、java线程Dump：线程mp是非常有用的诊断java应用问题的工具，每一个java虚拟机都有及时生成显示所有线程在某一点状态的线程mp的能力。虽然各个java虚拟机线程mp打印输出格式上略微有一些不同，但是线程mp出来的信息包含线程基本信息；线程的运行状态、猜宏标识和调用的堆栈；调用的堆栈包含完整的类名，所执行的方法，如果可能的话还有源代码的行数。
jstack是如何使用的？
实战案例如下： package concurrency; import java.io.IOException; import java.io.InputStream; public class Test { public static void main(String[] args) throws InterruptedException, IOException { InputStream is = System.in; int i = is.read(); System.out.println("exit。"); } }
❽ 如何在程序异常退出前输出当前进程的堆栈信息 Backtraces
打印堆栈是调试的常用方法，一般在系统异常时，我们可以将异常情况下的堆栈打印出来，这样十分方便错误查找。实际上还有另外一个非常有用的功能：分析代码的行为。android代码太过庞大复杂了，完全的静态分析经常是无从下手，因此通过打印堆栈的动态分析也十分必要。
Android打印堆栈的方法，简单归类一下
1. zygote的堆栈mp
实际上这个可以同时mp java线程及native线程的堆栈，对于java线程，java堆栈和native堆栈都可以得到。
使用方法很简单，直接在adb shell或串口中输入：
[plain] view plain
kill -3 <pid>
输出的trace会保存在 /data/anr/traces.txt文件中。这个需要注意，如果没有 /data/anr/这个目录或/data/anr/traces.txt这个文件，需要手工创建一下，并设置好读写权限。
如果需要在代码中，更容易控制堆栈的输出时机，可以用以下命令获取zygote的core mp:
[java] view plain
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一样的。
不过需要注意两点：
adb shell可能会没有权限，需要root。
android 4.2中关闭了native thread的堆栈打印，详见 dalvik/vm/Thread.cpp的mpNativeThread方法：
[cpp] view plain
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
mpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆栈的打印被关掉了！不过对于大多数情况，可以直接将这个注释打开。
2. debuggerd的堆栈mp
debuggerd是android的一个daemon进程，负责在进程异常出错时，将进程的运行时信息mp出来供分析。debuggerd生 成的coremp数据是以文本形式呈现，被保存在 /data/tombstone/ 目录下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10个文件，当超过10个时，会覆盖重写最早生成的文件。从4.2版本开 始，debuggerd同时也是一个实用工具：可以在不中断进程执行的情况下打印当前进程的native堆栈。使用方法是:
[plain] view plain
debuggerd -b <pid>
这可以协助我们分析进程执行行为，但最最有用的地方是：它可以非常简单的定位到native进程中锁死或错误逻辑引起的死循环的代码位置。
3. java代码中打印堆栈
Java代码打印堆栈比较简单， 堆栈信息获取和输出，都可以通过Throwable类的方法实现。目前通用的做法是在java进程出现需要注意的异常时，打印堆栈，然后再决定退出或挽救。通常的方法是使用exception的printStackTrace()方法：
[java] view plain
try {
...
} catch (RemoteException e) {
e.printStackTrace();
...
}
当然也可以只打印堆栈不退出，这样就比较方便分析代码的动态运行情况。Java代码中插入堆栈打印的方法如下：
[java] view plain
Log.d(TAG,Log.getStackTraceString(new Throwable()));
4. C++代码中打印堆栈
C++也是支持异常处理的，异常处理库中，已经包含了获取backtrace的接口，Android也是利用这个接口来打印堆栈信息的。在Android的C++中，已经集成了一个工具类CallStack，在libutils.so中。使用方法：
[cpp] view plain
#include <utils/CallStack.h>
...
CallStack stack;
stack.update();
stack.mp();
使用方式比较简单。目前Andoid4.2版本已经将相关信息解析的很到位，符号表查找，demangle，偏移位置校正都做好了。
[plain] view plain
5. C代码中打印堆栈
C代码，尤其是底层C库，想要看到调用的堆栈信息，还是比较麻烦的。 CallStack肯定是不能用，一是因为其实C++写的，需要重新封装才能在C中使用，二是底层库反调上层库的函数，会造成链接器循环依赖而无法链接。 不过也不是没有办法，可以通过android工具类CallStack实现中使用的unwind调用及符号解析函数来处理。
这里需要注意的是，为解决链接问题，最好使用dlopen方式，查找需要用到的接口再直接调用，这样会比较简单。如下为相关的实现代码，只需要在要 打印的文件中插入此部分代码，然后调用getCallStack()即可，无需包含太多的头文件和修改Android.mk文件：
[cpp] view plain
#define MAX_DEPTH 31
#define MAX_BACKTRACE_LINE_LENGTH 800
#define PATH "/system/lib/libcorkscrew.so"
typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);
typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);
typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);
static void *gHandle = NULL;
static int getCallStack(void){
ssize_t i = 0;
ssize_t result = 0;
ssize_t count;
backtrace_frame_t mStack[MAX_DEPTH];
backtrace_symbol_t symbols[MAX_DEPTH];
unwindFn unwind_backtrace = NULL;
unwindSymbFn get_backtrace_symbols = NULL;
unwindSymbFreeFn free_backtrace_symbols = NULL;
// open the so.
if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);
// get the interface for unwind and symbol analyse
if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");
if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");
if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");
if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols ){
ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",
gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );
return result;
}
count= unwind_backtrace(mStack, 1, MAX_DEPTH);
get_backtrace_symbols(mStack, count, symbols);
for (i = 0; i < count; i++) {
char line[MAX_BACKTRACE_LINE_LENGTH];
const char* mapName = symbols[i].map_name ? symbols[i].map_name : "<unknown>";
const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;
size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;
if (symbolName) {
uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;
if (pc_offset) {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s+%u)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName, pc_offset);
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName);
}
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s",
i, symbols[i].relative_pc, fieldWidth, mapName);
}
ALOGD("%s", line);
}
free_backtrace_symbols(symbols, count);
return result;
}
对sched_policy.c的堆栈调用分析如下,注意具体是否要打印，在哪里打印，还可以通过pid、uid、property等来控制一下，这样就不会被淹死在trace的汪洋大海中。
[plain] view plain
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00010e82 /system/lib/libutils.so (androidSetThreadPriority+61)
D/SchedPolicy( 1350): #03 pc 00068104 /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)
D/SchedPolicy( 1350): #04 pc 0001e510 /system/lib/libdvm.so (dvmPlatformInvoke+112)
D/SchedPolicy( 1350): #05 pc 0004d6aa /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)
D/SchedPolicy( 1350): #06 pc 00027920 /system/lib/libdvm.so
D/SchedPolicy( 1350): #07 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
D/SchedPolicy( 1350): #08 pc 00060c30 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)
D/SchedPolicy( 1350): #09 pc 0004cd34 /system/lib/libdvm.so
D/SchedPolicy( 1350): #10 pc 00049382 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #11 pc 00065e52 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #12 pc 0001435e /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+57)
D/SchedPolicy( 1350): #13 pc 00016f5a /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)
D/SchedPolicy( 1350): #14 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #15 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #16 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #17 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #18 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #19 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #20 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00016f26 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)
D/SchedPolicy( 1350): #03 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #04 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #05 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #06 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #07 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #08 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #09 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
6. 其它堆栈信息查询