1.有一个消费kafka 信息报文的任务，手动创建分区数的线程，每个线程（守护）分别消费每个分区的数据，offset存储在redis。 突然生产环境消费的速率特别慢，排除由于报文调用接口报错重试停留1s的问题后仍旧很慢。 通过jstack 查询该pid的堆栈信息，发现问题；kafka默认分区有35个分区，应该有35个kafka消费线程，但是打印出来却只有一个消费线程，测试环境正常的是有35个线程。 生产环境重启服务又恢复了消费，过几天又会无缘无故有线程小时很奇怪。 查询过资源 资源也是够得：
1.top命令查看CPU负载使用情况，在第三行中并显示的CPU负载的使用情况。
us：表示用户空间占用CPU的百分比；
sy：表示内核空间占用CPU的百分比；
ni：表示用户进程空间内改变过优先级的进程占用CPU的百分比；
id：空闲CPU的百分比；
wa：表示当前IO操作的CPU占用的百分比；
hi：表示硬中断占用CPU的百分比；
si：表示软中断占用CPU的百分比；
st：st为0表示流畅，CPU资源足够完全不需要等待，当数值增加时，表示服务器资源不够。
2.sar命令查看CPU负载使用情况。其相关参数含义如下：
%user：表示内核空间占用CPU的百分比；
%nice：表示用户进程空间内改变过优先级的进程占用CPU的百分比；
%system：表示内核空间占用CPU的百分比；
%iowait：表示当前IO操作的CPU占用的百分比；
%steal：表示vCPU占用物理CPU的百分比；
%idle：空闲CPU的百分比；
1.jstak 查询问题
jps -lm 查询java进程以及程序信息
2.统计线程数信息
1. jstack -l 22529 | grep 'java.lang.Thread.State' | wc -l
2. jstack -l 22529 | grep 'java.lang.Thread.State: RUNNABLE' | wc -l
3. jstack -l 22529 | grep 'Java-level deadlock' | wc -l
3.查看cpu占用高线程 定位线程所在的代码
[tomcat@localhost ~]$ top -Hp 22529
top - 15:10:21 up 146 days, 23:15, 1 user, load average: 0.00, 0.01, 0.05
Threads: 77 total, 0 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 7906868 total, 158892 free, 2796352 used, 4951624 buff/cache
KiB Swap: 8388604 total, 8306172 free, 82432 used. 4684500 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22529 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 0:00.00 java
22530 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 0:01.08 java
22531 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 2:12.77 java
22542 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 2:09.99 java
[tomcat@localhost ~]$ printf "%x\n" 22542
580e
[tomcat@localhost ~]$ jstack 22529 |grep 580e -A 20
"Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007f6d500c9000 nid=0x580e runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f6d500be000 nid=0x580d waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f6d50082000 nid=0x5808 in Object.wait() [0x00007f6d40ffe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000000806e0d58> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
