问题描述
Netty实例化一组请求处理程序类无论何时建立新连接打开.这对于像websocket这样的东西似乎很好，在websocket的整个生命周期中，连接将保持打开状态.
Netty instantiates a set of request handler classes whenever a new connection is opened. This seems fine for something like a websocket where the connection will stay open for the lifetime of the websocket.
将Netty用作HTTP服务器时，它每秒可以接收数千个请求，这似乎对垃圾回收会产生很大的负担.每个请求都实例化几个类(在我的情况下为10个处理程序类)，然后在几毫秒后进行垃圾回收.
When using Netty as an HTTP server which could receive thousands of requests per second this seems like it would be rather taxing on garbage collection. Every single request instantiates several classes (in my case 10 handler classes) and then garbage collects them some milliseconds later.
在中等负载〜1000 req/sec的HTTP Server中，这是一万类，用于实例化和每秒垃圾回收 .
In an HTTP Server with a moderate load ~1000 req/sec, that would be ten thousand classes to instantiate and garbage collect every second.
似乎我们可以 创建可共享的处理程序，以使用ChannelHandler.Sharable消除这种巨大的GC开销.它们只是必须是线程安全的.
It seems we could create sharable handlers that would eliminate this large GC overhead using ChannelHandler.Sharable. They just have to be thread safe.
但是，我发现库中打包的所有非常基本的HTTP处理程序都是 not 不可共享的，例如HttpServerCodec和HttpObjectAggregator.另外， HTTP都没有处理程序示例是可共享的. 99％的示例代码和教程似乎都不用理会它.诺曼·毛勒(Norman Maurer)的书( Netty作者)，其中提供了使用共享处理程序的原因:
However, I see that all the very basic HTTP Handlers that are packaged in the library are not sharable, like HttpServerCodec and HttpObjectAggregator. Also, none of the HTTP handler examples are sharable. 99% of example code and tutorials don't seem to bother with it. There was only one blurb in Norman Maurer's book (Netty author) which gives a reason for using a shared handler:
任何地方都没有提到GC负载问题.
No mention of GC load concerns anywhere.
Netty已在常规生产中使用了将近十年.对于高度并发的非阻塞IO，可以说是目前使用最广泛的Java库.
Netty has been in regular production use for almost a decade. It is arguable the most used java library in existence for highly concurrent non-blocking IO.
换句话说，它的目的是执行比我每秒1000个请求更多的任务.
In other words, it is designed to do much more than my moderate 1000 requests per second.
我是否错过了一些使GC加载不成问题的事情?
Is there something I missed that makes the GC load not a problem?
或者，我是否应该尝试实现自己的具有相似功能的Sharable处理程序，以对HTTP请求和响应进行解码，编码和写入?
Or, should I try to implement my own Sharable handlers with similar functionality for decoding, encoding and writing HTTP requests and responses?
推荐答案
尽管我们始终旨在尽可能减少网购产生的GC，但在某些情况下，这实际上是不可能的.例如，http编解码器等保持每个连接的状态，因此无法共享(即使它们是线程安全的).
While we always aim to produce as minimal GC as possible in netty there are just situations where this is not really possible. For example the http codecs etc keep state that is per connection so these can't be shared (even if they would be thread-safe).
解决此问题的唯一方法是将它们池化，但是我认为还有其他对象更有可能导致GC问题，因此，我们尝试在可能的情况下池化这些对象.
The only way around this would be to pool them but I think there are other objects which are much more likely to cause GC problems and for these we try to pool when easily possible.
这篇关于为什么Netty HTTP处理程序不可共享?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！