Java concurrent program basics-Excutor, java concurrent excutor

Java concurrent program basics-Excutor, java concurrent excutor
Overview

The Excutor interface is not used much, but ThreadPoolExcutor is used much. ThreadPoolExcutor is an implementation of Excutor. The Excutor system does not have any difficulties. Most of the key points and design ideas are described in special detail in javadoc. However, it is necessary to sort them out so that in subsequent development scenarios, make better use of the flexible APIs provided by jdk.

The Excutor interface is mainly used to decouple task executors and task initiators. The javadoc write of JDK 8 is very detailed. Therefore, the Excutor series of classes are all targeted at this goal. Of course, many implementation classes are enhanced in specific scenarios, saving developers time and effort, for example, ThreadPoolExcutor manages the thread pool. ScheduledThreadPoolExecutor provides the thread pool function and supports scheduled and fixed frequency tasks.

An object that executes submitted Runnable tasks. This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. 

Class Diagram

 

 

Extended Interface ExecutorService

ExecutorService strengthens Executor to track, manage, and stop tasks. Javadoc description:

An Executor that provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks.
An ExecutorService can be shut down, which will cause it to reject new tasks. Two different methods are provided for shutting down an ExecutorService. The shutdown() method will allow previously submitted tasks to execute before terminating, while the shutdownNow() method prevents waiting tasks from starting and attempts to stop currently executing tasks. Upon termination, an executor has no tasks actively executing, no tasks awaiting execution, and no new tasks can be submitted. An unused ExecutorService should be shut down to allow reclamation of its resources.
Method submit extends base method Executor.execute(Runnable) by creating and returning a Future that can be used to cancel execution and/or wait for completion. Methods invokeAny and invokeAll perform the most commonly useful forms of bulk execution, executing a collection of tasks and then waiting for at least one, or all, to complete. (Class ExecutorCompletionService can be used to write customized variants of these methods.)
 
 

ExecutorService is also extended to AbstractExecutorService and ScheduledExecutorService according to typical use cases. The former serves as the interface for real-time task processing, and the latter serves as the interface for processing scheduled/fixed frequency tasks.

AbstractExecutorService

AbstractExecutorService is positioned as a real-time task processing. Therefore, the submit returns the FutureTask object through which the caller can track and process the task.

Provides default implementations of ExecutorService execution methods. This class implements the submit, invokeAny and invokeAll methods using a RunnableFuture returned by newTaskFor, which defaults to the FutureTask class provided in this package. For example, the implementation of submit(Runnable) creates an associated RunnableFuture that is executed and returned. Subclasses may override the newTaskFor methods to return RunnableFuture implementations other than FutureTask.

ScheduledExecutorService

ScheduledExecutorService extends the ExecutorService and adds timing and fixed frequency control. In fact, ScheduledExecutorService also supports real-time execution api (excute (), and, by default, when the delay parameter value is 0 or negative, it is processed as a real-time task. The submit method of ScheduledExecutorService returns ScheduledFutureTask. Javadoc description:

An ExecutorService that can schedule commands to run after a given delay, or to execute periodically.
The schedule methods create tasks with various delays and return a task object that can be used to cancel or check execution. The scheduleAtFixedRate and scheduleWithFixedDelay methods create and execute tasks that run periodically until cancelled.
Commands submitted using the Executor.execute(Runnable) and ExecutorService submit methods are scheduled with a requested delay of zero. Zero and negative delays (but not periods) are also allowed in schedule methods, and are treated as requests for immediate execution.

Useful implementations ThreadPoolExecutor 

ThreadPoolExecutor is usually used in many cases. Generally, three methods of the Executors tool class are enough. If you need to customize the thread pool, pay attention to the combination of the queue and thread pool size parameters. Javadoc writes are more detailed, extracted, the rough part is the focus:

An ExecutorService that executes each submitted task using one of possibly several pooled threads, normally configured using Executors factory methods.
Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks.
To be useful across a wide range of contexts, this class provides many adjustable parameters and extensibility hooks. However, programmers are urged to use the more convenient Executors factory methods Executors.newCachedThreadPool() (unbounded thread pool, with automatic thread reclamation), Executors.newFixedThreadPool(int) (fixed size thread pool) and Executors.newSingleThreadExecutor() (single background thread), that preconfigure settings for the most common usage scenarios. Otherwise, use the following guide when manually configuring and tuning this class:

Core and maximum pool sizes

A ThreadPoolExecutor will automatically adjust the pool size (see getPoolSize()) according to the bounds set by corePoolSize (see getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()). When a new task is submitted in method execute(Runnable), and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle. If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. By setting corePoolSize and maximumPoolSize the same, you create a fixed-size thread pool. By setting maximumPoolSize to an essentially unbounded value such as Integer.MAX_VALUE, you allow the pool to accommodate an arbitrary number of concurrent tasks. Most typically, core and maximum pool sizes are set only upon construction, but they may also be changed dynamically using setCorePoolSize(int) and setMaximumPoolSize(int).

On-demand construction

By default, even core threads are initially created and started only when new tasks arrive, but this can be overridden dynamically using method prestartCoreThread() or prestartAllCoreThreads(). You probably want to prestart threads if you construct the pool with a non-empty queue.

Creating new threads uses a custom factory to group threads and set different priorities.

New threads are created using a ThreadFactory. If not otherwise specified, a Executors.defaultThreadFactory() is used, that creates threads to all be in the same ThreadGroup and with the same NORM_PRIORITY priority and non-daemon status. By supplying a different ThreadFactory, you can alter the thread's name, thread group, priority, daemon status, etc. If a ThreadFactory fails to create a thread when asked by returning null from newThread, the executor will continue, but might not be able to execute any tasks. Threads should possess the "modifyThread" RuntimePermission. If worker threads or other threads using the pool do not possess this permission, service may be degraded: configuration changes may not take effect in a timely manner, and a shutdown pool may remain in a state in which termination is possible but not completed.

Keep-alive times

If the pool currently has more than corePoolSize threads, excess threads will be terminated if they have been idle for more than the keepAliveTime (see getKeepAliveTime(TimeUnit)). This provides a means of reducing resource consumption when the pool is not being actively used. If the pool becomes more active later, new threads will be constructed. This parameter can also be changed dynamically using method setKeepAliveTime(long, TimeUnit). Using a value of Long.MAX_VALUE TimeUnit.NANOSECONDS effectively disables idle threads from ever terminating prior to shut down. By default, the keep-alive policy applies only when there are more than corePoolSize threads. But method allowCoreThreadTimeOut(boolean) can be used to apply this time-out policy to core threads as well, so long as the keepAliveTime value is non-zero.

Queuing focuses on direct transmission, unbounded queues, bounded queues, and typical use cases.

Any BlockingQueue may be used to transfer and hold submitted tasks. The use of this queue interacts with pool sizing:
   

    
If fewer than corePoolSize threads are running, the Executor always prefers adding a new thread rather than queuing.
    
If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread.
    
If a request cannot be queued, a new thread is created unless this would exceed maximumPoolSize, in which case, the task will be rejected.
   
There are three general strategies for queuing:

Rejected tasks

New tasks submitted in method execute(Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the executemethod invokes the RejectedExecutionHandler.rejectedExecution(Runnable, ThreadPoolExecutor) method of its RejectedExecutionHandler. Four predefined handler policies are provided:It is possible to define and use other kinds of RejectedExecutionHandler classes. Doing so requires some care especially when policies are designed to work only under particular capacity or queuing policies.

Hook methods is used to extend the thread pool Function

This class provides protected overridable beforeExecute(Thread, Runnable) and afterExecute(Runnable, Throwable) methods that are called before and after execution of each task. These can be used to manipulate the execution environment; for example, reinitializing ThreadLocals, gathering statistics, or adding log entries. Additionally, method terminated() can be overridden to perform any special processing that needs to be done once the Executor has fully terminated.
If hook or callback methods throw exceptions, internal worker threads may in turn fail and abruptly terminate.

ForkJoinPool

ForkJoinPool follows the 'divide and conquer 'idea. It splits tasks first. If necessary, it then combines the execution results and returns the results. Only tasks of the ForkJoinTask type can be executed. The RecursiveTask task returns results after execution, while the RecursiveAction task does not return results, which is suitable for tasks of the event-driven class.

Excutors

Excutors is a tool class that provides APIs for creating typical ThreadPoolExcutor and ScheduledThreadPoolExecutor instances. during development, you do not need to manually create a thread pool.

Summary

The Excutor System in java cocurrent package mainly provides real-time and scheduled (including fixed frequency) Excutor, which supports a single thread and thread pool; they are responsible for decoupling the task executor from the task publisher.

Real-time task processing can be used in the case of scheduled tasks. ScheduledThreadPoolExecutor also provides APIs that support real-time tasks.

The thread pool is usually created using Excutors. Typical thread pools are single, fixed-size thread pools, adjustable-size thread pools, and custom thread pools, you must configure the relationship between the queue size and the thread pool size.

Use the submit api to submit a task to the thread pool. Based on the actual scenario, use the Future api to monitor the task execution status. If necessary, stop the task in progress.

Workflow: Create a thread pool, create a task, submit a task, track and process the task results.