当新类型的线程运行时，更大的线程池或额外的 ExecutorService ？
我有一个与 Java 中 ExecutorService 的可能开销相关的问题。
当前的实现有 ExecutorService A，容量为 5 个线程。
- 它运行
A类型的线程。 A类型线程执行一些数据库读写操作。
现在，B 类型的线程将在 A 类型的一些 线程完成后运行。
- 将运行的类型
B线程的数量有时会有所不同。 - B 型线程执行一些文件系统 IO（不是数据库）。
那么我应该
- 添加一个新的 ExecutorService 来处理类型 B 线程
- 还是应该增加 ExecutorService A 的容量并运行类型 B /code> 也与那个线程相关吗？
我认为 Java 拥有两个 ExecutorService 可能会产生一些额外的开销，但另一方面，线程总数会增加。这有什么关系吗？
I have a question that is related to possible overhead of ExecutorServices in Java.
The present implementation has ExecutorService A with a capacity of 5 threads.
- It runs threads of type
A. - type
Athreads do some database reading and writing.
Now, a thread of type B will run after some threads of type A has finished.
- The number of type
Bthreads that will run is different from time to time. - type
Bthreads do some filesystem IO (not database).
So should I
- add a new
ExecutorServiceto handle typeBthreads - or should I increase the capacity of
ExecutorService Aand run typeBthreads with that one as well?
I'm thinking that there might be some extra overhead for Java to have two ExecutorServices, but on the other hand the total number of threads will increase either way. Does it matter at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我将推荐两个
ExecutorServices，然后您就可以利用java.util.concurrent包提供的不同ExecutorService了。它使代码更容易并且开销可以忽略不计。
ExecutorService一个固定线程池设置为五个线程。ExecutorServiceb 带有缓存的线程池。I will recommend two
ExecutorServices, then you can take advantage of the differentExecutorServices provided by thejava.util.concurrentpackage.It makes the code easier and the overhead is ignorable.
ExecutorServicea with a fixed thread pool set to five threads.ExecutorServiceb with a cached thread pool.如果您谈论的是 5 个线程，并且您没有耗尽线程池容量，那么我倾向于说，无论哪种方式，开销都是微不足道的，您应该采用您认为最简单的路线。
If you're talking about 5 threads, and you're not exhausting your thread pool capacity, I would tend to say that the overhead woulld be insignificant either way, and you should just go whatever you deem to be the simplest route.