JVM问题，一般会有三种情况，目前遇到了两种，线程溢出和JVM不够用

1.线程溢出：unable to create new native thread

1.1问题描述：

系统在1月4号左右，突然发现会产生内存溢出问题，从日志上看，错误信息为：

导致系统不能使用，对外不能相应，但是观察gc等又处于正常情况，free 系统内存也正常。开始重启机器进行解决，真正的原因查找，过程比较坎坷，经历也比较痛苦。

1.2 问题解决

• pstree查看线程数，发现系统线程数不断增长，直到OOM。

命令：pstree  -p pid (对该项已经加了监控)

• 线程过多导致的内存溢出，但是那里的线程过多呢？！

我们实现了ThreadFactory，通过它，给线程的加一个前缀。来标记线程所属。重现问题后，发现是task模块的TaskScheduler的定时任务中，在方法内使用

ExecutorService taskExecutor = Executors.newFixedThreadPool(nThreads);

taskExecutor.invokeAll(tasks);

导致回收不及时，发生了问题。

2.内存溢出：老生代100%无法及时回收

2.1问题现象：

1月31号，中午突然所有的机器陆续出现不能工作的现象，日志中看不到OOM错误，但是不能访问服务，或者访问非常的慢，观察jmap -heap发现老生代占用达到99%以上（不同版本JDK显示可能不一样。）

2.2 问题解决：

1、查看对内存使用情况，发现存在JVM堆内存不能释放的问题

   命令：jmap -heap pid   此命令有时候，会执行卡顿，不建议加监控

   语法：jmap - heap pid

2、进一步查看gc回收情况，发现FGC频率高，而且时间长，且回收不给力。

命令：jstat -gcutil pid 

语法：jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

另输出结果到文件的方法：jstat -gcutil PID 1000 > /root/monitor/jstat_`date +"%F"`.txt &

3、查看JVM堆中具体有哪些对象。发现不正常，Byte数组占用过大。实例达到1亿两千万，大小竟然有4g(3958M).同时，订单、hibernate引擎、mysql结果集类实例都很多。

命令：jmap -histo

语法：jmap -histo[:live] pid

见附件

 另只输出最大的100条的方法：jmap -histo:live ${_PID} | head -200

4、查看Mysql慢查询，发现确实找达到问题原因。

命令1:mysql数据库上查看，所有的。

命令2：查看当前慢查询

SELECT * from information_schema.`PROCESSLIST` ;(简化版：show PROCESSLIST)

5 、JAVA死锁

5.1 问题现象

       线程pstree -p pid 发现线程数，并不多，只有1770个，但是查看tomcat的访问日志和业务日志，用户请求不能处理，但是Spring的定时任务，还可以照常运行。jstat -gcutil 查看jvm没有OOM，但内存几乎也没有变动。

5.2 问题解决

      通过jstack -F pid 输出进程的线程列表，发现有死锁。