转自：http://www.cnblogs.com/mumuxinfei/p/4366708.html
前言:
最近小组在组织<<深入剖析Nginx>>的读书会, 里面作者提到了pstack这个工具. 之前写JAVA程序, 对jstack这个工具, 非常的喜欢, 觉得很有用. 于是想比较下pstack和jstack的异同.
和jstack一样, pstack亦能展现进程的线程堆栈快照, 非常方便验证和性能评估. 本文用来简单展示下pstack的使用方式和原理.
pstack使用
pstack使用非常的简单, 让我们写个简易多线程程序:
编译执行后, 使用pstack体验下:
注: 大秘密, sleep函数貌似是基于nanosleep实现的, ^_^.
这边我们能清楚的看到两个线程在执行线, 以及当前线程的详细函数栈信息.
对pstack的作用, 大致可以归纳如下:
1). 查看线程数(比pstree, 包含了详细的堆栈信息)
2). 能简单验证是否按照预定的调用顺序/调用栈执行
3). 采用高频率多次采样使用时, 能发现程序当前的阻塞在哪里, 以及性能消耗点在哪里?
4). 能反映出疑似的死锁现象(多个线程同时在wait lock, 具体需要进一步验证)
当然还能举例更多的作用, 相信使用过jstack的coder, 必然深以为然.
pstack原理:
pstack用途很大, 那其背后的原理是啥?
可以观察发现, 其实pstack是/usr/bin/gstack的软链接, 而gstack本身是基于gdb封装的shell脚本.
让我们简单分析下这个强大的shell脚本:
注: 由于代码太长, 这边选取最核心的片段, backtrace="thread apply all bt"
shell采用了here document的方式, 完成了GDB的交互工作(注意EOF标识, 及范围内的交互命令).
重要的是输入thread apply all bt这个交互命令. 该命令要求输出所有的线程堆栈信息.
对GDB输出的结果, 通过管道并借助sed命令进行了替换和过滤.
总结:
pstack其实是gdb的一个功能封装, 但其实现的功能, 确实非常实用. 本文讲述了pstack使用和原理, 以及常见的用途, 下文将讲述死锁检测的一种机制, 欢迎关注.
写在最后：
如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益. 无论多少, 都是对楼主一种由衷的肯定.
