单看javacore ,native_stderr.log,systemout.log 不看headdump .如何诊断OOM（内存溢出）错误？

内存溢出问题是最难诊断和定位的，即使看了heapdump，也难诊断。
因为分配内存的时候，不一定是系统要挂的时候，可能是长期的积累，可能是前段时间的分配不回收导致后面正常业务的时候出现out of memory。

javacore和SystemOut.log中只能看到出现了内存溢出的错误，能看到最后是由于那个线程申请不到内存而造成的溢出，但是无法知道是哪些对象把JVM的堆给占满了。所以要想知道堆被占满的真正原因，还是需要分析heapdump才可以。

可以尝试对比OOM前后时间点的不同的多个JavaCore线程的内容，来找到一个信息，但是要找到根源仍是需要HeapDump比较准确。

首先你得了解到heapdump,javacore和systemout/systemerr所记录的内容的区别：

1. heapdump是记录JVM中内存分配及对象使用,并且在内存溢出时产生。
2. javacore是记录线程池中线程的使用对象。
3. systemout/systemerr是记录日常JVM运行时的输出。
4. GC log是从JVM启动后，JVM的内存分配的大小变化及每次局部GC和full GC时所释放的JVM内存大小，总体来说会一直不断变化。

搞清楚这方面的问题的后，你还得搞清楚内存溢出的具体区别，内存溢出不一定就是堆溢出。也有可能是GC异常导致的，比如你的年轻代和年老代很配不合理导致GC出现异常等。还有就是常驻内存溢出，本地内存溢出等等。

日常最常见的就是堆内存溢出是JVM堆内存分配的内存被java对象占满时产生的错误。所以首先你得查看heapdump中所有的内存使用情况，找出占用JVM内存多的，当然也包括大对象什么的，比如你的JVM堆分配大小为1024m, JVM正常运行时，jvm的使用大比方说在200-500m之间，但是突然同时来了6个100m左右的数据对象申请比如说文件读取那么这种对象如果直接写到JVM内存也会导致堆内存溢出，而这类的JVM使用情况是记录在heapdump中的。
而javacore记录的是内存溢出时或者你手工生成时，线程池中线程的工作情况，你得结合一起查看，先查看heapdump的相关内存占用情况，再根据查找结果找出最大的占用JVM内存的对象，如果还是查找不出来，再去查看GC日志去查看内存使用的时间曲线，再去推断占用情况。

对 必须通过结合分析headdump文件来排错