The details from the JDK bug didn’t give me any hints: How could corePoolSize=0 cause JDK to consume 100% CPU? Scrolling down, I was very relieved by the top answer. However, I was really bothered by that unexpected behavior.ĭid I interpret the JavaDocs incorrectly? I was upset that I had to always consume a thread, but that’s the best I could do with the time available. So I was expecting the pool to only keep threads around temporarily.Īt this point, I switched to corePoolSize=1 to work around this unexpected behavior. The 10 minute delay was not super strict.ĬorePoolSize - the number of threads to keep in the pool, even if they are idle, unless allowCoreThreadTimeOut is set They even warn you not to set it to 0 in the documentation:Īdditionally, it is almost never a good idea to set corePoolSize to zero or use allowCoreThreadTimeOut because this may leave the pool without threads to handle tasks once they become eligible to run.īut I was okay with that, because I did not care about waiting for the pool to create a new thread. I intentionally used this because I did not want to continuously consume the resources needed for a thread for something that ran once every 10 minutes! ScheduledExecutorService executorService = Executors.newScheduledThreadPool(0) The author had the exact same line of code as me: ScheduledExecutorService consumes 100% CPU when corePoolSize = 0 Googling for ScheduledThreadPoolExecutor 100% CPU brings up a StackOverflow post that describes the same symptoms: He suggested I Google a bit and see what comes up. It was actually stuck in DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:809)! However, he took a closer look at the stack trace and noticed it wasn’t stuck in doSomethingReall圜heap()

It doesn’t look like an issue with doSomethingReall圜heap(). My co-worker took a look and agreed with me. On top of that, I intentionally chose scheduleWithFixedDelay in case it unexpectedly took longer than 10 minutes so that it would not overload the thread pool by adding more work when the previous instance of that task has not completed yet.Īt this point I was out of ideas, so I asked a coworker to double check my work.

There were other similar blocks of code scheduling this kind of work on application startup again, all of them were IO bound. This was something that runs only every 10 minutes and on top of that it was not CPU bound.

Imovie 10.1.7 quit unexpectedlky