看了上面的内容，并没有发现tomcat闪崩是由于老年代，持久代，新生代空间不足引起的。有好几次因为eden区空间使用到100%引起的full gc，但是垃圾回收过后eden区的空间都恢复到正常的水平。
日志中还记录了tomcat闪崩时heap堆的使用情况：
Heap PSYoungGen total 200960K, used 95671K [0x573c0000, 0x63bc0000, 0x63bc0000) eden space 197632K, 47% used [0x573c0000,0x5cf5d230,0x634c0000) from space 3328K, 55% used [0x63880000,0x63a50be0,0x63bc0000) to space 3584K, 0% used [0x634c0000,0x634c0000,0x63840000) ParOldGen total 843776K, used 423703K [0x23bc0000, 0x573c0000, 0x573c0000) object space 843776K, 50% used [0x23bc0000,0x3d985cc0,0x573c0000) PSPermGen total 262144K, used 51856K [0x03bc0000, 0x13bc0000, 0x23bc0000) object space 262144K, 19% used [0x03bc0000,0x06e64228,0x13bc0000)一切都那么正常，同时又那么诡异。
翻看了之前发生日志，内容都是大同小异。
重新翻看了几遍日志，这次把重点放在日志中建议的解决方案上：
# Reduce memory load on the system # Increase physical memory or swap space # Check if swap backing store is full # Use 64 bit Java on a 64 bit OS # Decrease Java heap size (-Xmx/-Xms) # Decrease number of Java threads # Decrease Java thread stack sizes (-Xss)其中下面几个解决方案不采用：
Reduce memory load on the system。 系统内存够用，32G的内存，还剩20G没用，无需减少内存。
Increase physical memory or swap space。 系统内存够用，32G的内存，还剩20G没用，无需增加物理内存。
Use 64 bit Java on a 64 bit OS。 32位操作系统，无法使用64位jdk。
只剩下下面的三个解决方案了：
Decrease Java heap size (-Xmx/-Xms)。 heap堆设置过大，就会影响剩余内存。
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
而减少java线程的数量，需要修改代码，这个也不实际。
最后只剩下
Decrease Java heap size (-Xmx/-Xms)
Decrease Java thread stack sizes (-Xss)
这两个解决方案了，就从这里入手，曙光就在前方。
先看 Decrease Java thread stack sizes (-Xss) 解决方案