Java Secrets: Using ExecutorService to run many background tasks.

Overview

Java has had support for thread pools for a many years, but using them is still black art for many. Part of the problem is that misusing a thread pool will make a program run slower not faster and cause the program to crash or even hang the system.

I often see people trying to use a queue, or wait/notify and thread(s) when an ExecutorService does all this for you.

Choosing the right thread pool

For different situations, different pools are useful. Sometimes it makes sense to have more than one to take advantage of their different characteristics.
Thread pool typeHow to createusesdisadvantages
Single threaded poolExecutors. newSingleThreadExecutor();Useful to event processing e.g. logs always performs tasks in order and minimises overheadOnly one thread
Fixed size poolExecutors. newFixedThreadPool (n_threads);Useful for using many cores, possibly all cores in your systemAlways has the same number of threads even if not used.
Cached thread poolExecutors. newCachedThreadPool();A good alternative to creating new threads for each task by re-cycling threadsThe number of threads is unlimited and incorrect use can bring a system to its knees.
Single threaded scheduling pool Executors. newSingleThreadScheduledExecutor (n_threads);Useful to event processing some with delaysOnly one thread
Multi threaded scheduling poolExecutors. newScheduledThreadPool();Fixed size pool for recurring and delay eventsAlways has the maximum number threads

Performance tips

The cost of a creating task in a pool can be significant and the smaller you make the task, the greater the overhead to real work being done.

Performing a loop across multiple threads

I have added an example program for the use of Executor.

The first example is single threaded. This should be the baseline of any performance test as there is no point using multiple threads if the task will be slower.

The second example shows that even with an optimal number of threads, making the tasks too small will make the task take much longer.

The third example uses as little tasks as possible which will still keep all the cores busy. This is usually optimal for a CPU intensive task.

The examples print
Single threaded: Time to geomean 1,000,000 values was 7.163 msecs. 
Too many tasks: Time to geomean 1,000,000 values was 601.613 msecs. 
One task per thread: Time to geomean 1,000,000 values was 2.349 msecs.

Code: ExecutorTestMain

Comments

Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

Image
  You still have to watch how many objects you create. This article looks at a benchmark passing events over TCP/IP at 4 billion events per minute using the net.openhft.chronicle.wire.channel package in Chronicle Wire and why we still avoid object allocations..  One of the key optimisations is creating almost no garbage. Allocation is a very cheap operation and collection of very short-lived objects is also very cheap. Does this really make a difference? What difference does one small object per event (44 bytes) make to the performance in a throughput test where GC pauses are amortised? While allocation is as efficient as possible, it doesn’t avoid the memory pressure on the L1/L2 caches of your CPUs and when many cores are busy, they are contending for memory in the shared L3 cache.  Results Benchmark on a Ryzen 5950X with Ubuntu 22.10. JVM Vendor, Version No objects Throughput, Average Latency* One object per event Throughput, Average Latency* Azul Zulu 1.8.0_322 60.6 M event/s, 528
Read more

System wide unique nanosecond timestamps

A Unique Identifier can be very useful for tracing. Those ids are even more useful when they contain a high-resolution timestamp.  Not only do they record the time of an event, but if unique can help trace events as they pass through the system. Such unique timestamps however can be expensive depending on how they are implemented.   This post explores a lightweight means of producing a unique, monotonically increasing system-wide nano-second resolution timestamp available in our open-source library. Uses for Unique Identifiers Unique identifiers can be useful to associate with a piece of information so that information can be referred to later unambiguously. This could be an event, a request, an order id, or a customer id. They can naturally be used as a primary key in a database or key/value store to retrieve that information later. One of the challenges of generating these identifiers is avoiding creating duplicates while not having an increasing cost.  You could record every identi
Read more

Comparing Approaches to Durability in Low Latency Messaging Queues

Image
  A significant feature of Chronicle Queue Enterprise is support for TCP replication across multiple servers to ensure the high availability of application infrastructure. I generally believe that replicating data to a secondary system is faster than syncing to disk, assuming the round trip network delay wasn’t high due to quality networks and co-located redundant servers. This is the first time I have benchmarked it with a realistic example. Little’s Law and Why Latency Matters In many cases, the assumption is that the latency won't be a problem as long as throughput is high enough. However, latency is often a key factor in why the throughput isn’t high enough. Little’s law states, “ the long-term average number  L  of customers in a  stationary  system is equal to the long-term average effective arrival rate  λ  multiplied by the average time  W  that a customer spends in the system”. In computer terminology, the level of concurrency or parallelism a system has to support must be
Read more