使用ThreadPoolExecutor，如何获取在线程池中运行的线程的名称？

Z时代
2024-01-10
分类：问答

我ThreadPoolExecutor在Java中使用A

来管理许多正在运行的线程。我创建了自己的简单名称，ThreadFactory以便为线程命名。

问题在于，在首次创建线程池时会在线程中设置名称，并且该名称与线程池实际正在运行的任务无关。我了解这一点…尽管我的Runnable和Callables具有名称，但它们实际上是从ThreadPoolExecutor的运行线程开始的抽象层。

关于为ThreadPoolExecutor线程池创建名称，StackOverflow上还有其他一些问题。（请参阅如何为可调用线程命名？和如何在Java中命名线程池的线程。）

我想知道的是：有没有人有一个很好的解决方案来保持线程池线程的名称与实际运行的Runnable同步？

即，如果我打电话，Thread.getCurrentThread().getName()我希望它不

返回顶级线程池的名称，而是返回线程当前正在运行的Callable / Runnable的名称。

由于这主要是出于调试和日志记录的目的，因此我试图避免一种解决方案，该方案涉及将新代码放入可能提交给ThreadPoolExecutor的每个Runnable中，我宁愿将一些代码放入ThreadFactory或包装ThreadPoolExecutor本身，以便在一处完成更改。如果不存在这样的解决方案，由于它不是关键任务，我可能不会打扰。

澄清为了澄清，我知道我可以将Thread.currentThread().setName( "my runnable name"

);Runnable的每个run方法的第一行放在第一行，但是我试图避免这样做。我在这里是一个完美主义者，我意识到这一点，所以如果人们想对此问题发表评论并告诉我，我不会感到生气。

我想，我的另一个问题是人们是否认为做这样的事情不是一个好主意。我应该谨慎地更新这样的线程池名称吗？

感谢您的任何建议！

回答：

创建一个重写beforeExecute方法的ThreadPoolExecutor。

private final ThreadPoolExecutor executor = new ThreadPoolExecutor (new ThreadPoolExecutor(10, 10,  0L, TimeUnit.MILLISECONDS,  new LinkedBlockingQueue<Runnable>()){   
    protected void beforeExecute(Thread t, Runnable r) { 
         t.setName(deriveRunnableName(r));
    }
    protected void afterExecute(Runnable r, Throwable t) { 
         Thread.currentThread().setName("");
    }
    protected <V> RunnableFuture<V> newTaskFor(final Runnable runnable, V v) {
         return new FutureTask<V>(runnable, v) {
             public String toString() {
                return runnable.toString();
             }
         };
     };
}

不确定会如何derveRunnableName()运作，也许toString()？

编辑：Thread.currentThread（）实际上是在调用afterExecute的beforeExecute中设置的线程。您可以引用Thread.currentThread（），然后在afterExecute中设置名称。这在javadocs中有所说明

/**
 * Method invoked upon completion of execution of the given Runnable.
 * This method is invoked by the thread that executed the task. If
 * non-null, the Throwable is the uncaught <tt>RuntimeException</tt>
 * or <tt>Error</tt> that caused execution to terminate abruptly.
 *
 * <p><b>Note:</b> When actions are enclosed in tasks (such as
 * {@link FutureTask}) either explicitly or via methods such as
 * <tt>submit</tt>, these task objects catch and maintain
 * computational exceptions, and so they do not cause abrupt
 * termination, and the internal exceptions are <em>not</em>
 * passed to this method.
 *
 * <p>This implementation does nothing, but may be customized in
 * subclasses. Note: To properly nest multiple overridings, subclasses
 * should generally invoke <tt>super.afterExecute</tt> at the
 * beginning of this method.
 *
 * @param r the runnable that has completed.
 * @param t the exception that caused termination, or null if
 * execution completed normally.
 */
protected void afterExecute(Runnable r, Throwable t) { }