笔记：
1.top命令找出最高占用的进程（command为java）
2.查看高负载进程下的高负载线程：top -Hp 【PID】 （或 ps -mp PID -o THREAD,tid,time）
3.找出最高占用的线程并记录thread_id，把线程号 进行换算成16进制编号：printf "%X\n" thread_id
4.（可选）执行查看高负载的线程名称：jstack 16143【进程】 | grep 3fb6【线程】
5.导出进程的堆栈日志，找到3fb6 这个线程号：jstack 16143 >/home/16143.log
PS. 其它可能用到的命令：
1.输入：top -H -p PID 或 ps -mp PID -o THREAD,tid,time
找出最高占用的线程并记录thread_id
2.查看dump信息（-a 30 意思打印30行）
jstack pid |grep 16进制的thread_id -a 30
或者导出
jstack pid |grep 16进制的thread_id -a 30 > xx.log
案例记录：
定位：根据运维反馈CPU负载非常高，初步判断是应用代码问题，某个线程长时间在跑，占用CPU资源，比如死循环等等。
1、执行：top
查看高负载的进程
2、top -Hp 16143
查看高负载进程下的高负载线程
把线程号 16310 进行换算成16进制编号：3fb6
3、jstack 16143 | grep 3fb6
执行查看高负载的线程名称
根据查询到得线程名称可以知道是消息消费线程高负载。
4、jstack 16143 >/home/16143.log
导出进程的堆栈日志，找到3fb6 这个线程号
通过跟踪代码，确认有问题的代码方法。
四、问题修复
1、update操作 使用select 语句
2、修改类型为update，提交解决
五、总结
1、因为是一步线程，所以监控平台无法监控到具体代码行数
2、线程已经卡住，没有任何得日志信息提示
3、是一个典型得需要通过打印堆栈才能排查得高负载问题