java troubleshooting

https://blog.csdn.net/Erica_1230/article/details/70215657
首先我们可以通过 top -Hp <pid> 来看这个进程里所有线程的cpu消耗情况，得到类似下面的数据

接着我们可以通过 jstack <pid> 的输出来看各个线程栈:

上面的线程栈我们注意到nid的值其实就是线程ID，它是十六进制的，我们将消耗cpu最高的线程 18250 ，转成十六进制 0x474a ，然后从上面的线程栈里找到 nid=0x474a 的线程，其栈为：
https://blog.csdn.net/linshizhan/article/details/78592477
1，使用命令top -p <pid> ，显示你的java进程的内存情况，pid是你的java进程号，比如123
2，按H，获取每个线程的内存情况
3，找到内存和cpu占用最高的线程pid，比如15248
4，执行 printf 0x%x 15248 得到 0x3b90 ,此为线程id的十六进制
5，执行 jstack 123|grep -A 10 3b90，得到线程堆栈信息中3b90这个线程所在行的后面10行
6，查看对应的堆栈信息找出可能存在问题的代码

https://blog.csdn.net/Tardis1/article/details/51693196
https://blog.csdn.net/yingfeng612/article/details/74672309

            看日志，很明显是org.hibernate.exception.ExceptionUtils.getCauseUsingWellKnowTypes(...)这里“卡住”了。这个线程是"RUNABLE"状态的，难道在这里发生了死循环?后来花了很多时间在debug状态下把这个问题重现了(Hibernate 3.3.1.GA版本，通过hessian调用远程服务器报SQLGrammarException异常，就会出现这个问题)。跟踪到hibernate源码里发现了问题:

1. public static int getThrowableCount(Throwable throwable) {  
2.         int count = 0;  
3.         while ( throwable != null ) {  
4.             count++;  
5.             throwable = ExceptionUtils.getCause( throwable );  
6.         }  
7.         return count;  
8. }  

         这个方法里，throwable和它的cause引用的同一个SQLGrammarException对象，导致在while这里产生了死循环。这肯定是hibernate的bug了。于是把hibernate升级到3.3.2.GA(原来是3.3.1.GA，不敢升太多)问题解决。

https://blog.csdn.net/hj7jay/article/details/79000657
经过前面的分析与排查，最终定位到一个时间工具类的问题，造成了服务器负载以及cpu使用率的过高。

• 异常方法逻辑：是把时间戳转成对应的具体的日期时间格式；
• 上层调用：计算当天凌晨至当前时间所有秒数，转化成对应的格式放入到set中返回结果；
• 逻辑层：对应的是数据平台实时报表的查询逻辑，实时报表会按照固定的时间间隔来，并且在一次查询中有多次（n次）方法调用。

那么可以得到结论，如果现在时间是当天上午10点，一次查询的计算次数就是 10*60*60*n次=36,000*n次计算，而且随着时间增长，越接近午夜单次查询次数会线性增加。由于实时查询、实时报警等模块大量的查询请求都需要多次调用该方法，导致了大量CPU资源的占用与浪费。