「内存溢出」Java服务内存溢出问题解决和总结

内存溢出

最近，公司测试环境服务发现一个问题：一个接口服务，合作方再调接口时，经常会出现连接超时异常（connection reset by peer）,紧接着看到服务内存100%，加内存也没用，不管加多少还是会缓慢升至100%。如下图：

通过各位大神的指点迷津，大概定位到以下问题：

程序出现内存泄漏，但泄漏不是太严重。
对象进入老年太，肯定有大量代码使用内存超过1M

对于1和2这两个问题，都表面代码肯定是有问题的。然后各位大佬开始出谋划策：

再加1个g观察是否继续到100%
用-Xms1024m -Xmx1024m限制jvm内存，根据使用情况限定内存超过后自行垃圾回收
new超过1M的，将对象进入对象池。对象池会反复减少gc
通过jstack定位哪些内存没有释放

对于2这种直接限制jvm内存的做法，能快速解决目前的问题，但是如果要求并发，增加处理速度，就必须改代码了。刚好这又是个接口程序，高并发实时性要求很严格。所以治标先治本，先用jstatck定位问题。

由于博主是小白，先学习一波jstatck命令：

jstatck简介:

jstack用于生成java 虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。

jstack参考：https://blog.csdn.net/zxp_cpinfo/article/details/54971115

先来补习一波linux命令：

top：在linux环境下，可以通过top命令查看各个进程的cpu使用情况，默认按cpu使用率排序;
top -Hp pid:通过top -Hp 23344可以查看该进程下各个线程的cpu使用情况，默认按cpu使用率排序;
jps -l:查看当前用户下的所有java进程，在root权限下及查看所以java程序进程。

上面两个命令可以看出pid为25077的线程占了较多的cpu资源，利用jstack命令可以继续查看该线程当前的堆栈状态。

线程对应的pid转成十六进制去dump文件查找，对应就是出问题的地方。

jstack命令

通过top命令定位到cpu占用率较高的线程之后，继续使用jstack pid命令查看当前java进程的堆栈状态。

jstack pid ：查看dump文件，直接显示
jstack -l pid > pid.stack:形成文件，从服务器下载下来后放到 IBM Thread and monitor Dump Analyzer for Java分析工具中分析。

分析结果如下：

分析报告出来了，就需要知道每项指标的含义：

1.dump 文件里，值得关注的线程状态有：

死锁， Deadlock（重点关注）

执行中，Runnable

等待资源， Waiting on condition（重点关注）

等待获取监视器， Waiting on monitor entry（重点关注）

暂停，Suspended

对象等待中，Object.wait() 或 TIMED_WAITING

阻塞， Blocked（重点关注）

停止，Parked

2.Dump文件中的线程状态含义及注意事项

Deadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。

Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递sql到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。

Waiting on condition：该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。

如果发现有大量的线程都在处在 Wait on condition，从线程 stack看，正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。

locked：线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。

Waiting for monitor entry 和 in Object.wait()：Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。

定位到是Waiting on condition问题，可能是接口服务回调超时等待404，把所有客户方的回调地址确认一波，看看情况~

未完待续，下回继续更！

Java服务内存溢出问题解决和总结

内存溢出

jstatck简介:

jstack命令

1.dump 文件里，值得关注的线程状态有：

2.Dump文件中的线程状态含义及注意事项

相关阅读

栏目导航

推荐阅读

热门阅读