Java concurrent programming practice-Chapter 6: task execution

Nonsense opening

Today, I started to learn Java concurrent programming practices, which many experts have recommended. So in order to leave some books on the road of concurrent programming, I also have this blog post. Today, I am mainly studying the task execution section, which mainly describes the task execution definition, Executor, thread pool, and Executor lifecycle. Most of them are conceptual. Please read them.

Start with the topic

Execute tasks in the thread

Two policies for thread-based task execution: one is to put all tasks in a single thread for serial execution, and the other is to put each task in its own thread for execution. Policy 1's problem lies in its poor responsiveness and throughput, and Policy 2's problem lies in the complexity of resource management.

ExecutorFramework

Executor simplifies thread management, and java. util. concurrent provides a flexible thread pool as part of the Executor framework. Executor is designed based on the producer-consumer model. The operation unit for submitting a task is equivalent to the producer (generating the Worker Unit to be completed), and the thread for executing the task is equivalent to the consumer (executing the worker units ).

Sample Code: TaskExecutionWebServer

NTHREADS = 100 Executor exec = main (String [] args) ServerSocket serverSocket = ServerSocket (80 (Socket connection = Runnable task =}View Code

Thread Pool

Literally, a resource pool is used to manage a group of homogeneous worker threads. Executing a task in a thread pool has more advantages than allocating one thread to each task: not only can the large overhead generated during the process of creating and destroying a thread be apportioned when processing multiple requests, another advantage is that when a request arrives, the working thread usually exists, so the execution of the task is not delayed because the thread is created. The Java class library provides four thread pools to meet different task execution requirements:

NewFixedThreadPool: a fixed-length thread pool, that is, there is an upper limit on the size of the thread pool.

NewCachedThreadPool: cache-able thread pool. If the current size of the thread pool exceeds the processing requirement, Idle threads will be reclaimed. When the demand increases, new threads can be added, note that there is no limit on the size of the thread pool.

NewSingleThreadExecutor: Single-threaded Executor. A single worker thread is created to execute tasks in sequence. If this thread ends abnormally, the Executor will create another thread. Note that this mode ensures that tasks are executed serially (such as FIFO, LIFO, and priority) in the order of the tasks in the queue ).

NewScheduledThreadPool: Creates a fixed-length thread pool and executes tasks in a delayed or scheduled manner.

ExecutorLifecycle

Executor usually creates a thread to execute the task, but the JVM will exit only after all (non-Daemon) threads terminate. Therefore, if Executor cannot be properly disabled, then the JVM will not end. To solve the problem of executing the service lifecycle, ExecutorService extends the Executor interface and adds a method for managing the lifecycle. ExecutorService has three major states: running, closing, and terminated.

The road is long, and I will go up and down

This is what I wrote today. I will introduce it in detail later.