补充netty文档阅读
This commit is contained in:
@@ -123,7 +123,20 @@ outbound event会按照自顶向下的顺序被outbound进行处理,outbound h
|
|||||||
// need to specify a group.
|
// need to specify a group.
|
||||||
pipeline.addLast(group, "handler", new MyBusinessLogicHandler());
|
pipeline.addLast(group, "handler", new MyBusinessLogicHandler());
|
||||||
```
|
```
|
||||||
当为BusinessLogicHandler指定DefaultEventExecutorGroup时,虽然会将操作从EventLoop中卸载,但是其针对每个ChannelHandlerContext仍然是串行进行处理的。故而,串行处理可能仍然会导致性能瓶颈。如果在用例场景下顺序不太重要时,可以考虑使用`UnorderedThreadPoolEventExecutor`来最大化任务的并行执行。
|
当为BusinessLogicHandler指定DefaultEventExecutorGroup时,虽然会将操作从EventLoop中卸载,但是其针对每个ChannelHandlerContext仍然是串行进行处理的(即先提交的task先执行)。故而,串行处理可能仍然会导致性能瓶颈。如果在用例场景下顺序不太重要时,可以考虑使用`UnorderedThreadPoolEventExecutor`来最大化任务的并行执行。
|
||||||
|
|
||||||
|
> ### DefaultEventExecutorGroup
|
||||||
|
> 当为handler指定DefaultEventExecutorGroup时,其ChannelHandlerContext中executor对应的是
|
||||||
|
> DefaultEventExecutorGroup中的其中一个,故而handler对所有任务的处理都通过同一个executor进行。
|
||||||
|
>
|
||||||
|
> DefaultEventExecutorGroup中,所有executor其类型都为`SingleThreadEventExecutor`,故而handler对所有任务的处理都是有序的。在前面的exectuor处理完成之前,后续任务都被阻塞。
|
||||||
|
|
||||||
|
> ### UnorderedThreadPoolEventExecutor
|
||||||
|
> UnorderedThreadPoolEventExecutor其实现了EventExecutorGroup,但是其`next`方法用于只返回其本身`(this)`.
|
||||||
|
>
|
||||||
|
> 并且,UnorderedThreadPoolEventExecutor继承了ScheduledThreadPoolExecutor,并可以指定线程数,故而,当为handler指定该类型为group时,提交给相同handler的tasks,可能会被不同的线程执行,不保证有序。
|
||||||
|
>
|
||||||
|
> 故而,针对同一handler,其后续任务无需等待前面任务执行完成之后再执行,这样能够提高吞吐量和并发度。
|
||||||
|
|
||||||
### ThreadSafety
|
### ThreadSafety
|
||||||
channelhandler可以在任何时刻添加到pipeline或从pipeline中移除,ChannelPipeline是线程安全的。例如,可以在交换敏感信息前添加encryption handler并且在交换完信息后将encryption handler移除。
|
channelhandler可以在任何时刻添加到pipeline或从pipeline中移除,ChannelPipeline是线程安全的。例如,可以在交换敏感信息前添加encryption handler并且在交换完信息后将encryption handler移除。
|
||||||
|
|||||||
Reference in New Issue
Block a user