ScheduledThreadPoolExecutor has some optimization potential
In a project of mine I have been using the ScheduledThreadPoolExecutor
as the executor doing the bulk of the work. Lots of millisecond-range
timeouts for UDP packets involved, which leads to a lot of threads
getting blocked on the STPE's queue lock.
I first tried to solve this by separating tasks that need immediate
execution into a separate pool using a LinkedTransferQueue, but that
didn't help as much as I hoped because the separate pool still had to
compete for the lock when spamming timeout-tasks to the STPE.
So I tried rolling my own scheduler service instead. The
implementation is fairly bare-bones though, merely fulfilling my needs.
Benchmarks (jmh code) below.
Some of the performance gains in the single-threaded case probably stem
from features that I didn't replicate, but if I didn't do anything
terribly wrong it shows that the STPE throughput *decreases* under
contention while the custom executor does scale up to the number of
physical cores (4).