相信大家都有一种感觉，在线服务内存OOM问题是最难定位的问题，但归根结底，最常见的原因是：资源不够，太多资源被应用消耗58到家架构部、运维部、58速运技术部联合进行了一次线上服务内存OOM问题排查实践，分享了三个内存OOM问题的位置方法。希望对大家有所帮助。Topic某台服务器上部署了Java服务，出现OutOfMemoryError。请问可能是什么原因，如何定位问题？不妨将服务进程的PID设置为10765（没错，就是CPU占用率高的倒霉进程《线上服务CPU100%问题快速定位实战》）。Java服务OOM的解决方法，最常见的原因有：可能是内存分配实在是太小了，正常业务使用内存比较多。一个对象频繁申请，没有释放，内存不断泄漏，导致内存耗尽某个资源。频繁应用，系统资源耗尽，例如：不断创建线程，不断发起网络连接更具体的，可以使用以下工具一一排查。1、确认内存本身是否分配太小方法：jmap-heap10765如上图，可以查看新生代和老年代堆内存的分配大小和使用情况，看是否是自己分配的太小。2、查找最耗内存的对象方法：jmap-histo:live10765|more说明：如上图所示，输入命令后，会以表格的形式显示存活对象的信息，并根据排序totheoccupiedmemorysize:实例占用的内存大小类名是不是很直观？对于实例数多、内存大的实例/类，需要有针对性地审查相关代码。上图中占用内存最多的对象是RingBufferLogEvent，一共占用了18M内存，属于正常使用范围。如果发现某个类型的对象占用内存较大（比如好几个G），很可能是该类型的对象创建过多而没有释放。例如：申请资源后，没有调用close()或dispose()就释放了资源。消费者消费缓慢（或停止消费），而生产者不断向队列中发布任务，导致队列中的任务过多。3、确认是否是资源耗尽工具：pstreenetstat检查进程创建的线程数和网络连接数。如果资源耗尽，也可能会出现OOM。这里介绍另一种方法，通过/proc/${PID}/fd/proc/${PID}/task，可以分别查看句柄详情和线程数。比如线上服务器sshd进程的PID为9339，查看上图ll/proc/9339/fdll/proc/9339/task，sshd一共占用了四个句柄0->标准输入1->标准输出2->标准错误输出3->socket（很容易认为是监听端口）sshd只有一个主线程PID9339，没有多线程。所以只要ll/proc/${PID}/fd|wc-lll/proc/${PID}/task|wc-l（效果等同于pstree-p|wc-l）就可以知道进程和线程打开的句柄数。对于线上服务器上的一个tomcat，查看proc下的fd目录和task目录，尤其是handlefd目录的查询，有意想不到的惊喜，一定要自己尝试。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
