如何获取ScheduledExecutorService调度的5个重复执行线程的执行时机？

嘿，这个问题其实很好解决，给你几个实用的方案，你可以根据自己的场景来选：

方案1：直接在业务线程中添加计时逻辑 #

最简单的方式就是在你的workerThread的run()方法里，直接记录执行的开始和结束时间，计算耗时。这样每个线程自己负责跟踪自己的执行情况，非常直观：

// 假设你的workerThread是类似这样的Runnable实现
public class APIWorker implements Runnable {
    private int threadId;

    public APIWorker(int threadId) {
        this.threadId = threadId;
    }

    @Override
    public void run() {
        // 记录开始时间
        long startTime = System.currentTimeMillis();
        try {
            // 这里是你的API获取数据逻辑
            fetchDataFromAPI();
        } finally {
            // 记录结束时间并计算耗时
            long endTime = System.currentTimeMillis();
            long executionTime = endTime - startTime;
            System.out.printf("线程[%d]本次执行完成，耗时：%d 毫秒%n", threadId, executionTime);
        }
    }

    private void fetchDataFromAPI() {
        // 实际的API请求代码
        // 比如：RestTemplate.getForObject(...) 或者 HttpClient调用
    }
}

这个方案的优势是简单直接，不需要额外的代码结构，适合快速调试或者小规模的任务场景。

方案2：用装饰器模式包装任务，解耦计时与业务逻辑 #

如果你不想修改原有的workerThread代码，可以用装饰器模式把计时逻辑封装成一个独立的Runnable，然后把业务任务委托给它。这样计时逻辑和业务逻辑完全分离，更符合开闭原则：

// 通用的计时包装类
public class TimedTaskWrapper implements Runnable {
    private final Runnable targetTask;
    private final int taskId;

    public TimedTaskWrapper(Runnable targetTask, int taskId) {
        this.targetTask = targetTask;
        this.taskId = taskId;
    }

    @Override
    public void run() {
        long startNanos = System.nanoTime();
        try {
            // 执行原业务任务
            targetTask.run();
        } finally {
            long endNanos = System.nanoTime();
            long durationMs = TimeUnit.NANOSECONDS.toMillis(endNanos - startNanos);
            System.out.printf("任务[%d]本次执行耗时：%d 毫秒%n", taskId, durationMs);
            // 如果需要持久化，这里可以把时间写入日志文件、数据库或者监控系统
        }
    }
}

然后在提交任务的时候，用这个包装类把你的workerThread包起来：

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(5);
for (int i = 0; i < 5; i++) {
    // 用TimedTaskWrapper包装原任务
    scheduler.scheduleWithFixedDelay(
        new TimedTaskWrapper(Constant.workerThread[i], i),
        0,
        20,
        TimeUnit.SECONDS
    );
}

这个方案适合不想改动原有业务代码的场景，而且包装类可以复用在其他需要计时的任务上。

方案3：结合日志框架实现生产级监控 #

如果是在生产环境中，你可能需要更规范的记录方式，比如用SLF4J+Logback这类日志框架来结构化记录执行时间，方便后续的日志分析和监控：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MonitoredTaskWrapper implements Runnable {
    private static final Logger logger = LoggerFactory.getLogger(MonitoredTaskWrapper.class);
    private final Runnable targetTask;
    private final int taskId;

    public MonitoredTaskWrapper(Runnable targetTask, int taskId) {
        this.targetTask = targetTask;
        this.taskId = taskId;
    }

    @Override
    public void run() {
        long startTime = System.currentTimeMillis();
        logger.info("任务[{}]开始执行，时间戳：{}", taskId, startTime);
        
        try {
            targetTask.run();
            long endTime = System.currentTimeMillis();
            logger.info("任务[{}]执行成功，耗时：{}ms，结束时间戳：{}", 
                taskId, endTime - startTime, endTime);
        } catch (Exception e) {
            long endTime = System.currentTimeMillis();
            logger.error("任务[{}]执行失败，耗时：{}ms，结束时间戳：{}", 
                taskId, endTime - startTime, endTime, e);
        }
    }
}

这样的日志可以被收集到ELK、Grafana这类监控系统中，用来可视化任务的执行时间趋势、失败率等指标，非常适合生产环境的长期监控需求。

注意点 #

你用的是scheduleWithFixedDelay，这个方法的逻辑是上一次任务结束后，等待20秒再执行下一次，所以任务的执行时间不会影响间隔时间。如果是scheduleAtFixedRate的话，情况会不同，但你的场景下这个逻辑是没问题的。

内容的提问来源于stack exchange，提问作者Enaam Riyadh