Netty4 introduced the new Thread Model, perhaps you should tune your code to improve performance. Here are a few points from the Netty Wiki , and there are more changes to netty4.
3.x does not have a well-defined flow model, although there has been an attempt to correct its inconsistency in 3.5. 4.0 defines a strict stream model that helps the user write ChannelHandler without worrying about thread safety.
Netty will never call ChannelHandler methods at the same time, unless ChannelHandler is annotated with @Sharable. This is independent of the type of handler methods — inbound, outbound, or event lifecycle methods.
The user no longer needs to synchronize the processing methods for incoming or outgoing events.
4.0 prohibits adding ChannelHandler more than once if it is not annotated with @Sharable.
It always happens - until the relationship between the ChannelHandler method calls made by Netty.
The user does not need to define a volatile field to preserve the state of the handler. A user can specify an EventExecutor when he adds a handler to ChannelPipeline.
If specified, ChannelHandler handler methods are always called by the specified EventExecutor.
If not specified, the handler methods are always called by EventLoop so that the channel associated with it is registered.
EventExecutor and EventLoop assigned to a handler or pipe are always single-threaded.
Handler methods will always be called by the same thread.
If a multithreaded EventExecutor or EventLoop is specified, one of the streams will be selected first, and then the selected stream will be used until the registration is canceled.
If two EventExecutors are assigned to two handlers in the same pipeline, they are called simultaneously. The user should pay attention to thread safety if more than one handler accesses shared data, even if access to shared data is done only by handlers in the same pipeline. ChannelFutureListeners added to ChannelFuture are always called by the EventLoop stream assigned to the future linked channel.