将任务在线程池之间传递，对效率影响大吗？

Question

我有一个应用，大概是一个netty线程池和两个业务线程池。现在的流程是，netty线程池接受消息，然后将任务扔入业务线程池，业务线程池处理完消息后，直接将结果通过网络传送给客户。我觉得如果业务线程池处理完以后，将回复消息再扔回netty线程池，由netty负责消息的收发，逻辑上会更直观一些。但是不知道这样将任务扔来扔去是否会影响效率。因为要new一些runnable，以及需要修改线程池的任务队列等等。请指点。

Answer 1

当业务线程返回给netty线程池时，要考虑如果netty线程池已满，那么该业务线程就要等待了。
个人觉得，如果线程非常多，那么等待的时间可能会长一点，这个问题可能是影响效率的主要原因。
楼主说的线程扔来扔去，那可以线程池自己去维护，速度要比你想像的快的多，不是影响效率的原因。

Answer 2

谢谢楼上。发现回复给用户的时候不能再扔回netty线程池，因为netty的多线程可能将我业务中的有序数据乱序发出。
所以还是维持原来的设计了。

Answer 3

4楼说也有道理，不过LZ的想法也可行，职责分的更清楚些。LZ的业务线程多余接受线程，我猜测业务线程执行的时间要显然多接收线程的时间。
打个比方，接收需要2S，执行需要4S，这样的话，按照既存的逻辑，两个线程池的线程大多时候都在工作。空闲的线程少。LZ的想法是把发送的逻辑也放到接收线程中，个人感觉，要取决于发送逻辑执行的时间。时间少的话，不存在等待时间的话，可以放过去。如果多的话，发送的业务也可以放在一个线程池中处理。

Answer 4

嗯，谢谢6L。我之前是想职责分得更清楚一些，不过后来发现业务数据到达客户端可能乱序，所以就不扔回netty线程池了。我的业务只是因为职责的不同，分了几个池（每个池可能用不同的实现），但是并不是说线程总量就一定大于netty线程。并且我的瓶颈其实还是在网络IO上，大部分请求不需要做很多运算即可返回。

Answer 5

网络IO的话，尽量用java nio里面的类。