一次关于Netty+Gson促成内存泄露的分析排查

一次关于Netty+Gson造成内存泄露的分析排查

最近做了一个内部系统之间的数据同步服务器，client端通过socket发送经过压缩的json数据到server端，server完成数据解码和保存。server架构：netty+Gson解码

在做压力测试的时候，竟然发现server内存泄露。分析内存泄露的时候，其实我们可以从简单方法入手，因为jdk1.6后自身就带有不错的内存分析工具，而且我认为使用好这些工具基本足够高，因为如果你对这些工具的理解不深入，即使再强大的工具也是对你帮助不大。

开始分析：

第一步：jmap -heap <pid> 看个内存快照

using thread-local object allocation.
Parallel GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 536870912 (512.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 21757952 (20.75MB)
   MaxPermSize      = 67108864 (64.0MB)
   G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 160563200 (153.125MB)
   used     = 131079984 (125.00761413574219MB)
   free     = 29483216 (28.117385864257812MB)
   81.63762555803571% used
From Space:
   capacity = 9175040 (8.75MB)
   used     = 0 (0.0MB)
   free     = 9175040 (8.75MB)
   0.0% used
To Space:
   capacity = 9043968 (8.625MB)
   used     = 0 (0.0MB)
   free     = 9043968 (8.625MB)
   0.0% used
PS Old Generation
   capacity = 357957632 (341.375MB)
   used     = 357954568 (341.37207794189453MB)
   free     = 3064 (0.00292205810546875MB)
   99.9991440327776% used
PS Perm Generation
   capacity = 25690112 (24.5MB)
   used     = 25614800 (24.428176879882812MB)
   free     = 75312 (0.0718231201171875MB)
   99.70684440768495% used

10160 interned Strings occupying 880136 bytes.

经过一段时间运行，内存老生代满了，而且一直释放不了。
结合jcosonle运行图会更直观

一次关于Netty+Gson促成内存泄露的分析排查

这时候，再结合命令：jstat -gcutil <pid> 10000 20查看内存使用和回收快照，发现几十次大量的轻回收和全回收，轻回收每次时间达到2秒。

第二部：既然确定存在内存泄露，那么就定位谁泄露，这一般是最难的地方。使用命令：jmap -histo <pid>

num     #instances         #bytes class name
----------------------------------------------
   1:       1186682       85441104 java.lang.reflect.Field
   2:       1186506       56952288 com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1
   3:       1271453       50858120 java.util.LinkedHashMap$Entry
   4:        733627       38708968 [C
   5:       1268334       30440016 com.google.gson.reflect.TypeToken
   6:        437746       29974120 [I
   7:        215160       22299464 [Ljava.util.HashMap$Entry;
   8:        122745       17675280 java.text.DecimalFormat
   9:        191610       14843680 [Ljava.lang.Object;
10:        122746       13747552 java.util.GregorianCalendar
11:        122746       11783616 sun.util.calendar.Gregorian$Date
12:        116114       10890136 [B
13:        336981       10783392 java.util.HashMap$Entry

。。。。。

Total 11229733 542330424

就凭前两句，我大概断定是gson的问题。产生了大量gson的类。

1: 1186682 85441104 java.lang.reflect.Field
2: 1186506 56952288 com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1

但是，我是不会怀疑是gson的问题，而是在思考是不是使用方式不正确。

第三部：代码分析

gson是放在decoder里面对报文进行解码的

out.add(new Gson().fromJson(new String(beanBytes), Trade.class));

这里省略1万字各种测试对比，反正最后结果改成这样：

private static final Gson gson = new Gson();//做成单例
......
out.add(gson.fromJson(new String(beanBytes), Trade.class));

第四部：压测验证结果

一次关于Netty+Gson促成内存泄露的分析排查

从图片显而易见，没有内存泄露，最后那一条下坠的横线，是我为了确认问题，做了一次全回收，回收后，内存释放到只有20多M，非常好。

PS:为什么这写有问题，我也没搞明白，希望哪位大牛指点下。

一次关于Netty+Gson促成内存泄露的分析排查

相关推荐