Netty HashedWheelTimer过多导致内存泄漏的排错

背景：

CentOS release 5.6 (Final)

Netty 3.6.5 final

 

 

在一次压力测试中，发现Netty Based服务器连上4500+的clients就开始一直FullGC。

GC日志：

 

 

Java代码  

1. 2013-07-01T09:24:52.328+0800: 227629.120: [Full GC [PSYoungGen: 116544K->112471K(233024K)] [ParOldGen: 699071K->699071K(699072K)] 815615K->811543K(932096K) [PSPermGen: 15071K->15056K(21248K)], 0.6043590 secs] [Times: user=2.34 sys=0.00, real=0.60 secs]   
2. 2013-07-01T09:24:52.961+0800: 227629.753: [Full GC [PSYoungGen: 116544K->112514K(233024K)] [ParOldGen: 699071K->699071K(699072K)] 815615K->811586K(932096K) [PSPermGen: 15056K->15056K(21248K)], 0.6133040 secs] [Times: user=2.37 sys=0.00, real=0.61 secs]   

 

 

看出来年老代已经腾不出空间了。结果很明显，有对象导致了内存泄漏。

 

 

Java代码  

1. jmap -histo XXXX  

 查看堆使用情况

 

 

Java代码  

1. num     #instances         #bytes  class name  
2. ---------------------------------------------  
3.   1:      10252320      410092800  org.jboss.netty.util.internal.ConcurrentIdentityHashMap$Segment  
4.   2:      10332783      330649056  java.util.concurrent.locks.ReentrantLock$NonfairSync  
5.   3:      10252320      328462016  [Lorg.jboss.netty.util.internal.ConcurrentIdentityHashMap$HashEntry;  
6.   4:       2563074      123027552  org.jboss.netty.util.internal.ConcurrentIdentityHashMap  
7.   5:       2563072      123027456  org.jboss.netty.util.internal.ConcurrentIdentityHashMap$KeyIterator  
8.   6:       2563074       82018464  [Lorg.jboss.netty.util.internal.ConcurrentIdentityHashMap$Segment;  
9.   7:       2563072       41009152  org.jboss.netty.util.MapBackedSet  
10.   8:       2563072       41009152  org.jboss.netty.util.internal.ConcurrentIdentityHashMap$KeySet  
11.   9:        258183       12392784  org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout  

 

看第一行，有10252320 个 org.jboss.netty.util.internal.ConcurrentIdentityHashMap$Segment 对象！

 

同时发现cpu的占用非常平凡

于是查看线程情况，看到很多类似下面的timer线程：

 

Java代码  

1. jstack XXX  

 

Java代码  

1. "Hashed wheel timer #9086" prio=10 tid=0x00002aab886a7000 nid=0xe9f waiting on condition [0x00002aaba4380000]  
2.    java.lang.Thread.State: TIMED_WAITING (sleeping)  
3.         at java.lang.Thread.sleep(Native Method)  
4.         at org.jboss.netty.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:504)  
5.         at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:402)  
6.         at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)  
7.         at java.lang.Thread.run(Thread.java:722)  

 

 

发现很多timer线程，足足有5006个。

 

思考：测试压了5000个链接，也就是说timer/channel。可能这两者有关联，先解决timer问题。

 

查看new HashedWheelTimer的代码，发现有一处代码在每次连接时new了一个HashedWheelTimer，但是没有使用，fix it。（当然过程稍微复杂，没写的这么简单）

 

接着想线程跟内存泄漏的联系，看源码最实际，于是发现了这些timer是怎么把内存吃掉的。

 

默认每个Wheel有512个槽位，每个槽是一个MapBackedSet，每个MapBackedSet包含一个ConcurrentIdentityHashMap，每个ConcurrentIdentityHashMap默认大小为4。

 

 

Java代码  

1. public HashedWheelTimer(  
2.             ThreadFactory threadFactory, long tickDuration, TimeUnit unit) {  
3.         this(threadFactory, tickDuration, unit, 512);  
4.     }  

 

 

Java代码  

1. for (int i = 0; i < wheel.length; i ++) {  
2.             wheel[i] = new MapBackedSet<HashedWheelTimeout>(  
3.                     new ConcurrentIdentityHashMap<HashedWheelTimeout, Boolean>(16, 0.95f, 4));  
4.         }  

 

512 × 5000 × 4 = 10240000

 

很接近于10252320这个数字。OK，所有问题都解决了～！