Introduced Thread Pool Optimizations

[amitjoy]

fixes #1392

[CLAassistant]

All committers have signed the CLA.

[amitjoy]

FYI @cdjackson @ViToni @TomTravaglino

[cdjackson]

@amitjoy for information, does the problem you reported in #1392 actually still exist - ie is this PR actually needed? I'm not necessarily against merging this, but it's really a backstop and I'm wondering if the other PRs that have been merged by @ViToni actually prevent the threads being created in the first place?

[amitjoy]

@cdjackson Actually, this PR complements the changes @ViToni has already introduced. The important change @ViToni introduced is to enable removal of ScheduledFuture instances from the working queue that are already cancelled but the change I introduced is to ensure that there should not be any idle thread waiting for tasks for longer time and consume resources perpetually.

For example, here https://github.com/zsmartsystems/com.zsmartsystems.zigbee/blob/51d650319ac4d790a5ddad6c30cda261402209a7/com.zsmartsystems.zigbee/src/main/java/com/zsmartsystems/zigbee/ZigBeeExecutors.java#L57

we created a thread pool having a core pool size of n number of threads and when the executor is created all the n threads will be created by the JVM directly even if there may be m no of tasks where m < n. So, the n - m no of threads are parked idle and they will never be removed unless we allow timeout to them. So, now with the changes I introduced, the n - m no of threads will keep on waiting for x no of seconds (keepAlive timeout) and if there is no task assigned to the thread pool, the idle core threads will automatically be removed from the thread pool, therefore, spare resources.

Since, this is a library that can be used in any environment, I strongly believe that such changes are necessary to ensure less resource utilization even if the consumers create thread pool with large number of threads.

[cdjackson]

Thanks.