Java中的可重置计时器性能

在分析我的应用程序时，我发现了频繁分配的来源。。。我正在使用多个计时器检查超时（~2ms，随应用程序状态而变化）

根据所述，

ScheduledThreadPoolExecutor

比

Timer

更可取。所以，我的课程非常类似于按照建议安排任务的课程。我这样使用它：

private final ResettableTimer timer = new ResettableTimer(new Runnable() {
    public void run() {
        //timeout, do something
    }
});

timer.reset(2, TimeUnit.MILLISECONDS);

我发现每次安排任务时，java都会分配以下内容：

java.util.concurrent.LinkedBlockingQueue$Node

-16字节

java.util.concurrent.Executors$RunnableAdapter

-16字节

java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask

-64字节

java.util.concurrent.locks.AbstractQueuedSynchronizer$node

-28字节

例如：2个计时器，500个任务/秒=124kB/s

这很小，但会导致非常频繁的垃圾收集。它现在似乎并没有给我带来问题，尽管它可能是我在旧设备上看到的一些口吃的原因。我应该担心吗

---

更重要的是，这些分配似乎非常不必要，因为这些任务一遍又一遍地做着同样的事情。有什么方法可以避免这种重新分配吗？

计划执行器的要点是，它允许您计划单个任务以固定的时间间隔运行。如果您使用它每2ms重新安排一次相同的任务，那么您几乎将其用作一个普通的执行者。124k/s在桌面虚拟机上是微不足道的，但可能android的gc对于短期对象没有那么有效。@vanza我正在使用一个调度执行器，以便调用

ScheduledExecutorService.Schedule

来调度我的超时，并延迟运行。直接使用ExecutorService.submit和sleep（）是否更好？我的意思是，如果可以的话，你应该安排一段延迟和周期的任务；这样，每次执行都可以重复使用相同的任务，而不必每隔2ms安排一个新任务。@vanza不幸的是，在我的例子中没有固定的周期。时间的变化取决于应用程序状态，以及我的上一个计时器是否超时。我试图在我的问题中澄清这一点。。。（~2ms，随应用程序状态变化）