3

I have some very old (mid 2000s) code that instantiates objects based on incoming data from network IO, and each of these objects contains a private (non-static) timer and kicks off a scheduled TimerTask corresponding to a serialized object that comes from said network IO. The task they are doing is some cleanup on the object as it builds up from the IO.

It seemed like a good idea at the time....

I've been running into some availability problems recently and tracked down at least part of the fault to this code. Turns out when tens of thousands of these objects are created, my TimerTasks run me out of memory.

Is there a good 2018 (Java 8 presently, soon converting to 11) solution, perhaps some sort of thread pooling? The individual tasks are for cleaning up the individual object, so I don't mind if they run concurrently, but should also not kill my JVM in the process. And it is ok if some part of them gets delayed if there are many.

Any suggestions?

Smrtnik
  • 43
  • 3
  • 9
    "perhaps some sort of thread pooling" - You're looking for `ExecutorService`, possibly `ScheduledExecutorService` – Jacob G. Sep 18 '18 at 22:17
  • 2
    Staticallly create Executors.newScheduledThreadPool(numOfThreads) then schedule cleanup tasks using the scheduled executor service. – Roy Shahaf Sep 18 '18 at 22:38

0 Answers0