一个“简单的” java中的线程池

发布于 2024-11-09 21:41:54 字数 332 浏览 0 评论 0原文

我正在寻找一个简单的对象来容纳我的工作线程,并且我需要它不限制线程的数量,并且不让它们的存活时间超过所需的时间。 但我确实需要它有一个类似于 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一腔孤↑勇 2024-11-16 21:41:54

实现您想要的效果的一种方法是使用 CallableFuture,返回已完成上传的 File 对象。然后将 Future 传递到另一个 Callable 中,该 Callable 检查 Future.isDone() 并旋转直到返回 true,然后对文件执行任何您需要执行的操作。您的用例并不独特,并且非常适合 java.util.concurrent 包功能

一个有趣的类是 ExecutorCompletionService class 它完全按照您想要的方式等待结果,然后继续进行额外的计算。

使用一个 CompletionService
提供Executor来执行任务。
本班安排提交的
任务完成后,被放置在
使用 take 可访问的队列。这
类足够轻量级
适合短暂使用时
处理任务组。

使用示例:假设您有一组针对某个问题的求解器,
每个返回某种类型的值
结果,并想运行它们
同时处理结果
其中每个返回非空值
值,在某些方法中使用(Result r)。
您可以将其写为:

   void solve(Executor e, Collection<Callable<Result>> solvers)
              throws InterruptedException, ExecutionException 
   {
       CompletionService<Result> ecs = new ExecutorCompletionService<Result>(e);
       for (Callable<Result> s : solvers) { ecs.submit(s); }
       int n = solvers.size();
       for (int i = 0; i < n; ++i) 
       {
           Result r = ecs.take().get();
           if (r != null) { use(r); }
       }
   }

您不想要无限制的 ExecutorService

您几乎永远不想允许无限制的线程池,因为如果线程数量失控,它们实际上会限制应用程序的性能。

您的域受到磁盘或网络 I/O 或两者的限制,因此一个小的线程池就足够了。您不会想尝试从每个连接一个线程的数百或数千个传入连接中读取数据。

如果您收到多个并发上传,解决方案的一部分是调查 java.nio package 并阅读有关非阻塞 I/O 的信息。

One way to do what you awant is to use a Callable with a Future that returns the File object of a completed upload. Then pass the Future into another Callable that checks Future.isDone() and spins until it returns true and then do whatever you need to do to the file. Your use case is not unique and fits very neatly into the java.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.

A CompletionService that uses a
supplied Executor to execute tasks.
This class arranges that submitted
tasks are, upon completion, placed on
a queue accessible using take. The
class is lightweight enough to be
suitable for transient use when
processing groups of tasks.

Usage Examples: Suppose you have a set of solvers for a certain problem,
each returning a value of some type
Result, and would like to run them
concurrently, processing the results
of each of them that return a non-null
value, in some method use(Result r).
You could write this as:

   void solve(Executor e, Collection<Callable<Result>> solvers)
              throws InterruptedException, ExecutionException 
   {
       CompletionService<Result> ecs = new ExecutorCompletionService<Result>(e);
       for (Callable<Result> s : solvers) { ecs.submit(s); }
       int n = solvers.size();
       for (int i = 0; i < n; ++i) 
       {
           Result r = ecs.take().get();
           if (r != null) { use(r); }
       }
   }

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.

计㈡愣 2024-11-16 21:41:54

您是否有不想重用线程的原因?在我看来,最简单的事情就是使用 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文