Netty(4): Performance

Besides the event style design that we can learn from Netty, we can also learn experiences it used to optimize networking communication.

Object Pool

Buffer Recycle: Reference Count

As we all known, Java has many powerful garbage collector and algorithms (G1, CMS; and notice that reference count is not a valid GC algorithm, which can’t solve cyclic reference) to clean up unused object and free memory. In most cases, we don’t need to care about object creation and de-allocation thanks to the work of GC.

But, sometimes, we need object pools to do some optimizations (in most cases, this is not necessary and may make thing worse). One of examples like this is connection pool which is expensive to create.

In order to do object pooling, we need to adopt the reference count in case of explicit de-allocate and the Buffer recycle in Netty is implemented by this feature. More general, objects supporting recycling all implement io.netty.util.ReferenceCounted.

Error Detection

Considering that allocate and de-allocate is not done automatically, it is no doubt that leak may happen:

• If we forget to inc reference count: accessing an object whose reference count is zero causes an error;
• Or, we forgot to to decrement: So we risk causing memory overconsumption which may not be detectable until after several days, by exhaustion of memory. To quickly detect such a case, Netty provides a property-enabled auditing mechanism system. If an object is collected while its reference counter is greater than 0, so Netty logs an exception indicating the state of the stack at the time of allocation. The application code can also “mark” instances of ReferenceCounted with a message in order to trace their life cycle.

This is implemented in ResourceLeakDetector, which take advantage of PhantomReference's feature: object is put in ReferenceQueue if only accessed via PhantomReference.

DefaultResourceLeak ref = (DefaultResourceLeak) refQueue.poll();
// ...
String records = ref.toString();  
if (reportedLeaks.putIfAbsent(records, Boolean.TRUE) == null) {  
    if (records.isEmpty()) {  
        logger.error("LEAK: {}.release() was not called before it's garbage-collected. " +  
                "Enable advanced leak reporting to find out where the leak occurred. " +  
                "To enable advanced leak reporting, " +  
                "specify the JVM option '-D{}={}' or call {}.setLevel() " +  
                "See http://netty.io/wiki/reference-counted-objects.html for more information.",  
                resourceType, PROP_LEVEL, Level.ADVANCED.name().toLowerCase(), simpleClassName(this));  
    } else {  
        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);  
    }  
}

Mis

The following is some lists cited from some blogs:

• Netty supports a “Thread affinity” library to attach a thread to a processor core, and limit the risks cache invalidation.
• Netty recognizes the named pipes of Unix (“named pipes”) for communicate with resident processes on the same machine. It is reputed much faster than passing through the virtual interface Localhost.
• If asked nicely, Netty transfers data directly from the mass memory to the network card using Direct Memory Access (“Direct Memory Access”)
• Netty can apply a back pressure on a TCP connection, ie Netty does not send the acknowledgment TCP before the application code has had time to consume the received data: in other word,
• A standardized approach to the division of labor between threads associated with communication channels ( “Channels”).
• Stackable protocols (TLS, gzip, HTTP, WebSockets, ProtoBuf …)
• Declare variable as constants;
  • exception
  • HTTP constants

Ref

• Memory recycle of

Written with StackEdit.