[Netty4] ResourceLeakDetector implemented using a netty of [netty-common]

ResourceLeakDetector use and implementation of the netty

By WeakReference and ReferenceQueue do for the need to manually release detection resources

use

  1. Set the log level:
ServerBootstrap b =new ServerBootstrap();
b.group(bossGroup,workerGroup).channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 2048)
.handler(new LoggingHandler(LogLevel.DEBUG))
.childHandler(new ChildChannelHandler());

2017-01-19 10:04:49  [ nioEventLoopGroup-1-0:1628830 ] - [ ERROR ]  LEAK: ByteBuf.release() was not called before it's garbage-coll...
  1. ResourceLeakDetector.setLevel (ResourceLeakDetector.Level.ADVANCED); or by configuration parameters JVM
    log:
2017-01-19 10:35:59  [ nioEventLoopGroup-1-0:665092 ] - [ ERROR ]  LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 5
#5:
    io.netty.buffer.AdvancedLeakAwareByteBuf.readBytes(AdvancedLeakAwareByteBuf.java:435)

analysis

[ ERROR ] LEAK:

// ResourceLeakDetector
protected void reportTracedLeak(String resourceType, String records) {
    logger.error(
            "LEAK: {}.release() was not called before it's garbage-collected. " +
            "See http://netty.io/wiki/reference-counted-objects.html for more information.{}",
            resourceType, records);
}

private void reportLeak() {
    if (!logger.isErrorEnabled()) {
        clearRefQueue();
        return;
    }

    // Detect and report previous leaks.
    for (;;) {
        @SuppressWarnings("unchecked")
        DefaultResourceLeak ref = (DefaultResourceLeak) refQueue.poll(); // 为什么能拿到?什么时候 放进去的?是weakreference回收过程中放进去的,相当于GC过程让你插入hook。那为什么被GC了还有资源泄露呢?这个问题其实是这样的,泄露是池化内存等那些需要手动释放资源。
        if (ref == null) {
            break;
        }

        if (!ref.dispose()) { // return allLeaks.remove(this); 所以当有人显式释放过,那么此处就返回false 就不会往下走report了
            continue;
        }

        String records = ref.toString();
        if (reportedLeaks.putIfAbsent(records, Boolean.TRUE) == null) {
            if (records.isEmpty()) {
                reportUntracedLeak(resourceType);
            } else {
                reportTracedLeak(resourceType, records);
            }
        }
    }
}

The basic principle is to achieve:

  1. By DefaultResourceLeak inherited from WeakReference, by means of GC properties WeakReference completed. GC WeakReference characteristics of the object when the referenced object is not strong when other references, merely WeakReference reference (or other references to weak), GC will be recovered when the next time, the recovery process will be recovered in reference into ReferenceQueue. ReferenceQueue here is when you create DefaultResourceLeak by constructing a parameter passed.
  2. From time to time poll that ReferenceQueue queue, when the object is to get the looks dispose Whether been called, if not then do not show proof of release, the report came out.
  3. Each time the pool of buf object is created, it will create DefaultResourceLeak, and call its record in touch methods such as API, a track where the application uses. After tracing the leak in the open, buf will be packaging, such as packaging into AdvancedLeakAwareByteBuf.
  4. Detection reportLeak not always called when rain PARANOID level at the time of application buf random number greater percentages. PARANOID level is full tone.

Here resource leaks, refers to the kind of resources required to manually release, because he has been the object reference is not used in the program logic, it will eventually be recovered GC, but the kind of resources required to manually release does not explicitly released on leaked . Such as memory pool, say there are five cups, you use buf points to a cup occupied by you, when you do not explicitly tell the memory pool to say this cup No, it has been occupied, but not the objects buf will be recovered GC, so this time it leaked memory pool resources.

Guess you like

Origin www.cnblogs.com/simoncook/p/11980170.html