jvm core

最近遇到一个jvm core(hotspot)的问题，在$HOME目录下生成n多hserr_%pid%.log错误文件，有时候会生成java.core文件。在之前的性能测试和压力测试中均为发现有core file出现，无法手动重现，只有在测试组的自动化测试环境中才能重现。

崩溃的原因并非堆或永久代（元数据区）溢出，异常栈也不规定，有的是在JIT编译过程，有的是在创建线程。

从表象上看是jvm本身崩溃，一般错误日志都指出malloc或mmap函数调用异常（malloc返回null或mmap errno 12)，无法申请到内存了。

最一开始怀疑是内存不足引发kernel的OOM killer，后来发现系统的over_commit一直是关闭状态。

于是怀疑是系统内存不足，但是从日志文件可以看到，一般系统都有空闲（free)内存几百MB到2GB不等，最多的一次竟然还有4GB空闲内存，在学习了linux的内存管理之后，依然不理解为何还有空闲内存和swap空闲依然会发生malloc为null和mmap errno12的错误，在测试程序里死循环吃内存也可以重现这种错误。

最后为了揪出吃内存的进程，写了个脚本，监测实时进程统计数据，最后发现是另外一个产品，在重负荷下，起了几十个进程处理数据流，每个进程占用内存40-60MB不等，不由得佩服对面的实力，非常有效的策略，进程启动先把内存申请上，并起一组进程处理大数据流，这样保证本事进程内存可控，又不会被系统杀掉，真是很有经验。

最后是测试方法，测试组的自动化测试设置了8小时的schedule，前后的schedule有重合，导致压力增加，内存不足发生core dump.

如果想知道什么时候系统不再给内存，还需要对内核非常了解才行。