Tag: daemon

如何在multithreading环境中更好地使用ExecutorService？

我需要创建一个库，在其中我将有同步和异步方法。 executeSynchronous() – 等到我有结果，返回结果。 executeAsynchronous() – 立即返回一个Future，如果需要，可以在其他事情完成后处理。 我的图书馆的核心逻辑 客户将使用我们的库，他们将通过传递DataKey构建器对象来调用它。 然后，我们将使用该DataKey对象构造一个URL，并通过执行它来对该URL进行HTTP客户端调用，然后在我们将响应作为JSON字符串返回之后，我们将通过创建将该JSON字符串发送回我们的客户DataResponse对象。 有些客户会调用executeSynchronous() ，有些可能会调用executeAsynchronous() ，这就是为什么我需要在我的库中单独提供两个方法。 接口： public interface Client { // for synchronous public DataResponse executeSynchronous(DataKey key); // for asynchronous public Future executeAsynchronous(DataKey key); } 然后我有我的DataClient实现上面的Client接口： public class DataClient implements Client { private RestTemplate restTemplate = new RestTemplate(); // do I need to have all threads as […]

在ExecutorService上安排的守护程序线程; 解释为什么这是不好的forms

我对使用ExectuorService安排的线程有序关闭的想法很满意; 也就是说，调用shutdown或shutdownNow将导致池上创建的线程正常退出。 如果他们响应interrupt你可以确定最终会被调用等等，你将得到一个干净，可预测的退出（你可以清理任何资源等）。 但是，如果您已将线程设置为守护程序（通过执行程序的ThreadFactory ），如下所示。 ExecutorService pool = Executors.newSingleThreadExecutor(new ThreadFactory() { @Override public Thread newThread(Runnable runnable) { Thread thread = Executors.defaultThreadFactory().newThread(runnable); thread.setDaemon(true); return thread; } }); 主线程终止后，VM将突然终止任何守护程序线程。 在上面的示例中，调度然后突然终止的（守护程序）线程将绕过任何finally块，并且任何可中断的方法都不会抛出InterruptedException 。 所以，我倾向于认为将ThreadPoolExecutor使用的线程标记为守护进程是不好的做法……我的问题是关于帮助我发声的原因 。 为什么在ExecutorService的线程池中使用守护程序线程是不好的做法（或者如果你不同意）？ 特别是我有兴趣通过正常关闭（具有中断策略并且运行良好的线程）与守护程序线程来描述VM关闭的生命周期。 扩展最后一点，在ThreadPoolExecutor上finalize将自己调用shutdown ，但是当它使用守护进程线程时，如果VM调用了finalize ，它们可能已经终止。 那么线程池的行为是什么？ 如果底层线程突然终止，它是否可以被欺骗以保持活动状态（因此不会退出VM）？ 我问的部分原因是因为我已经看到它曾经绕过了关闭实际的ExectorService的需要。 您能想到绕过其关闭生命周期会产生不良影响的情况吗？ 到目前为止，我能够提出使用守护进程的唯一原因是采取捷径，我想欣赏它可能导致的任何意外的副作用。