一个“简单的” java中的线程池
我正在寻找一个简单的对象来容纳我的工作线程,并且我需要它不限制线程的数量,并且不让它们的存活时间超过所需的时间。 但我确实需要它有一个类似于 ExecutorService.shutdown(); 的方法 (等待所有活动线程完成但不接受任何新线程)
所以线程池可能不是我所需要的,所以我希望朝正确的方向推动。 (因为它们是为了使线程保持活动状态)
进一步澄清意图:
每个线程都是文件的上传,并且我有另一个修改文件的进程,但它等待文件没有任何上传。通过连接每个线程。因此,当它们保持活动状态时,它会锁定该进程。 (每个线程在创建时将自己添加到特定文件的列表中,因此我仅 join() 上传特定文件的线程)
I'm looking for a simple object that will hold my work threads and I need it to not limit the number of threads, and not keep them alive longer than needed.
But I do need it to have a method similar to an ExecutorService.shutdown();
(Waiting for all the active threads to finish but not accepting any new ones)
so maybe a threadpool isn't what I need, so I would love a push in the right direction.
(as they are meant to keep the threads alive)
Further clarification of intent:
each thread is an upload of a file, and I have another process that modifies files, but it waits for the file to not have any uploads. by joining each of the threads. So when they are kept alive it locks that process. (each thread adds himself to a list for a specific file on creation, so I only join() threads that upload a specific file)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
实现您想要的效果的一种方法是使用
Callable
和Future
,返回已完成上传的File
对象。然后将Future
传递到另一个Callable
中,该Callable
检查Future.isDone()
并旋转直到返回true
,然后对文件执行任何您需要执行的操作。您的用例并不独特,并且非常适合java.util.concurrent
包功能。一个有趣的类是 ExecutorCompletionService class 它完全按照您想要的方式等待结果,然后继续进行额外的计算。
您不想要无限制的 ExecutorService
您几乎永远不想允许无限制的线程池,因为如果线程数量失控,它们实际上会限制应用程序的性能。
您的域受到磁盘或网络 I/O 或两者的限制,因此一个小的线程池就足够了。您不会想尝试从每个连接一个线程的数百或数千个传入连接中读取数据。
如果您收到多个并发上传,解决方案的一部分是调查
java.nio
package 并阅读有关非阻塞 I/O 的信息。One way to do what you awant is to use a
Callable
with aFuture
that returns theFile
object of a completed upload. Then pass theFuture
into anotherCallable
that checksFuture.isDone()
and spins until it returnstrue
and then do whatever you need to do to the file. Your use case is not unique and fits very neatly into thejava.util.concurrent
package capabilities.One interesting class is
ExecutorCompletionService
class which does exactly what you want with waiting for results then proceeding with an additional calculation.You don't want an unbounded ExecutorService
You almost never want to allow unbounded thread pools, as they actually can limit the performance of your application if the number of threads gets out of hand.
You domain is limited by disk or network I/O or both, so a small thread pool would be sufficient. You are not going to want to try and read from hundreds or thousands of incoming connections with a thread per connection.
Part of your solution, if you are receiving more than a handful of concurrent uploads is to investigate the
java.nio
package and read about non-blocking I/O as well.您是否有不想重用线程的原因?在我看来,最简单的事情就是使用 ExecutorService 并让它重用线程。
Is there a reason that you don't want to reuse threads? Seems to me that the simplest thing would be to use ExecutorService anyway and let it reuse threads.