From the Blogosphere
Finally Getting the Most out of the Java Thread Pool | @CloudExpo #JVM #Java #Cloud
Thread pool is a core concept in multithreaded programming that represents a collection of idle threads used to execute tasks
By: Stackify Blog
Nov. 16, 2017 01:00 PM
Finally Getting the Most out of the Java Thread Pool
First, let's outline a frame of reference for multithreading and why we may need to use a thread pool.
A thread is an execution context that can run a set of instructions within a process - aka a running program. Multithreaded programming refers to using threads to execute multiple tasks concurrently. Of course, this paradigm is well supported on the JVM.
Although this brings several advantages, primarily regarding the performance of a program, multithreaded programming can also have disadvantages - such as increased complexity of the code, concurrency issues, unexpected results and adding the overhead of thread creation.
In this article, we're going to take a closer look at how the latter issue can be mitigated by using thread pools in Java.
Why Use a Thread Pool?
For a better understanding of the cost of creating and starting a thread, let's see what the JVM actually does behind the scenes:
Of course, the details of all this will depend on the JMV and the operating system.
In addition, more threads mean more work for the system scheduler to decide which thread gets access to resources next.
A thread pool helps mitigate the issue of performance by reducing the number of threads needed and managing their lifecycle.
Java Thread Pools
The java.util.concurrent package contains the following interfaces:
Alongside these interfaces, the package also provides the Executors helper class for obtaining executor instances, as well as implementations for these interfaces.
Generally, a Java thread pool is composed of:
In the following sections, let's see how the Java classes and interfaces that provide support for thread pools work in more detail.
The Executors class and Executor interface
Let's use these two classes in conjunction with an example that creates a single-thread pool, then uses it to execute a simple statement:
Notice how the statement can be written as a lambda expression - which is inferred to be of Runnable type.
The execute() method runs the statement if a worker thread is available, or places the Runnable task in a queue to wait for a thread to become available.
Basically, the executor replaces the explicit creation and management of a thread.
The factory methods in the Executors class can create several types of thread pools:
Next, let's take a look into what additional capabilities the ExecutorService interface.
Besides the execute() method, this interface also defines a similar submit() method that can return a Future object:
As you can see in the example above, the Future interface can return the result of a task for Callable objects, and can also show the status of a task execution.
The ExecutorService is not automatically destroyed when there are no tasks waiting to be executed, so to shut it down explicitly, you can use the shutdown() or shutdownNow() APIs:
The schedule() method specifies a task to be executed, a delay value and a TimeUnit for the value:
Furthermore, the interface defines two additional methods:
The scheduleAtFixedRate() method executes the task after 2 ms delay, then repeats it at every 2 seconds. Similarly, the scheduleWithFixedDelay() method starts the first execution after 2 ms, then repeats the task 2 seconds after the previous execution ends.
In the following sections, let's also go through two implementations of the ExecutorService interface: ThreadPoolExecutor and ForkJoinPool.
In this manner, the thread pool is preconfigured for the most common cases. The number of threads can be controlled by setting the parameters:
Digging a bit further, here's how these parameters are used.
If a task is submitted and fewer than corePoolSize threads are in execution, then a new thread is created. The same thing happens if there are more than corePoolSize but less than maximumPoolSize threads running, and the task queue is full. If there are more than corePoolSize threads which have been idle for longer than keepAliveTime, they will be terminated.
In the example above, the newFixedThreadPool() method creates a thread pool with corePoolSize=maximumPoolSize=10, and a keepAliveTime of 0 seconds.
If you use the newCachedThreadPool() method instead, this will create a thread pool with a maximumPoolSize of Integer.MAX_VALUE and a keepAliveTime of 60 seconds:
The parameters can also be set through a constructor or through setter methods:
A subclass of ThreadPoolExecutor is the ScheduledThreadPoolExecutor class, which implements the ScheduledExecutorService interface. You can create this type of thread pool by using the newScheduledThreadPool() factory method:
This creates a thread pool with a corePoolSize of 5, an unbounded maximumPoolSize and a keepAliveTime of 0 seconds.
The fork/join framework is based on a "work-stealing algorithm". In simple terms, what this means is that threads that run out of tasks can "steal" work from other busy threads.
A ForkJoinPool is well suited for cases when most tasks create other subtasks or when many small tasks are added to the pool from external clients.
The workflow for using this thread pool typically looks something like this:
To create a ForkJoinTask, you can choose one of its more commonly used subclasses, RecursiveAction or RecursiveTask - if you need to return a result.
Let's implement an example of a class that extends RecursiveTask and calculates the factorial of a number by splitting it into subtasks depending on a THRESHOLD value:
The main method that this class needs to implement is the overridden compute() method, which joins the result of each subtask.
The actual splitting is done in the createSubtasks() method:
Finally, the calculate() method contains the multiplication of values in a range:
Next, tasks can be added to a thread pool:
ThreadPoolExecutor vs. ForkJoinPool
When choosing a thread pool, it's important to also remember there is overhead caused by creating and managing threads and switching execution from one thread to another.
The ThreadPoolExecutor provides more control over the number of threads and the tasks that are executed by each thread. This makes it more suitable for cases when you have a smaller number of larger tasks that are executed on their own threads.
By comparison, the ForkJoinPool is based on threads "stealing" tasks from other threads. Because of this, it is best used to speed up work in cases when tasks can be broken up into smaller tasks.
To implement the work-stealing algorithm, the fork/join framework uses two types of queues:
When threads run out of tasks in their own queues, they attempt to take tasks from the other queues. To make the process more efficient, the thread queue uses a deque (double ended queue) data structure, with threads being added at one end and "stolen" from the other end.
Here is a good visual representation of this process from The H Developer:
In contrast with this model, the ThreadPoolExecutor uses only one central queue.
One last thing to remember is that the choosing a ForkJoinPool is only useful if the tasks create subtasks. Otherwise, it will function the same as a ThreadPoolExecutor, but with extra overhead.
Tracing Thread Pool Execution
By adding some logging statements in the constructor of FactorialTask and the calculate() method, you can follow the invocation sequence:
Here you can see there are several tasks created, but only 3 worker threads - so these get picked up by the available threads in the pool.
Also notice how the objects themselves are actually created in the main thread, before being passed to the pool for execution.
This is actually a great way to explore and understand thread pools at runtime, with the help of a solid logging visualization tool such as Prefix.
The core aspect of logging from a thread pool is to make sure the thread name is easily identifiable in the log message; Log4J2 is a great way to do that by making good use of layouts for example.
Potential Risks of Using a Thread Pool
To mitigate these risks, you have to choose the thread pool type and parameters carefully, according to the tasks that they will handle. Stress-testing your system is also well-worth it to get some real-world data of how your thread pool behaves under load.
And, the great thing about the Java ecosystem is that you have access to some of the most mature and battle-tested implementations of thread-pools out there, if you learn to leverage them properly and take full advantage of them.
The post Finally Getting the Most out of the Java Thread Pool appeared first on Stackify.
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week