When you create a task to be executed in X time, does the thread burden the pool or the OS even in that X time or only at the execution? Who is responsible for the countdown of that X time?

Edited January 23, 20224 yr by Hustman

If you properly use L2J ThreadPoolManager implementation, you simply pick a thread from an existing pool and once executed it returns to the pool - similar to a db connection factory.

 

L2J implementation is nothing more than dedicated ThreadPoolExecutor / ScheduledThreadPoolExecutor, 4 of each types.

 

You can read more on Google, as introduction : 

https://www.baeldung.com/thread-pool-java-and-guava

https://www.geeksforgeeks.org/thread-pools-java/

 

And whatever related to ThreadPoolExecutor / ScheduledThreadPoolExecutor classes.

15 hours ago, Tryskell said:

If you properly use L2J ThreadPoolManager implementation, you simply pick a thread from an existing pool and once executed it returns to the pool - similar to a db connection factory.

 

L2J implementation is nothing more than dedicated ThreadPoolExecutor / ScheduledThreadPoolExecutor, 4 of each types.

 

You can read more on Google, as introduction : 

https://www.baeldung.com/thread-pool-java-and-guava

https://www.geeksforgeeks.org/thread-pools-java/

 

And whatever related to ThreadPoolExecutor / ScheduledThreadPoolExecutor classes.

Thank you for answering, very instructive article. However, I am unable to locate in the ScheduledThreadPoolExecutor section, who is responsible for the delay countdown. Does the thread also perform this function? Does this mean that it uses CPU resources even before executing?

Edited January 24, 20224 yr by Hustman

The thread is simply an executable class, the ScheduledThreadPoolExecutor handles the management of it. How ? Who cares, it was optimized for you by some high-grade dudes years ago and added directly in Java.

 

Seeing how much tasks are generated by seconds (network, AI, and random tasks), it probably costs almost none CPU/RAM. You only have to assure yourself to avoid to bottleneck the system.

 

Not sure why you need this answer, your best bet is to make tests yourself because litteraly none did that before you (at least, I didn't).

What you can try to do is to change dynamically each executor's thread size based on your current cpu usage (ThreadPoolExecutor#setCorePoolSize). Although, i don't think that you will need such an optimization.

4 hours ago, Zake said:

What you can try to do is to change dynamically each executor's thread size based on your current cpu usage (ThreadPoolExecutor#setCorePoolSize). Although, i don't think that you will need such an optimization.

The only thing I want to know is, who is responsible for the countdown of the delay, that's all.

new thread waits for execute runnable. It means jvm calling OS for new thread when you create scheduled execution (that's for single Timer). ScheduledThreadPoolExecutor works asynchronously 

Edited April 29, 20224 yr by amaranthe92