Shulou(Shulou.com)06/02 Report--

This article focuses on "what happens to thread pools using Java unbounded queues". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what happens to the thread pool using Java unbounded queues"!

(1) background introduction

Today, I'd like to talk to you about a Java interview question from a big Internet company: will using thread pools with unbounded queues cause memory to soar?

Because in the face of Internet manufacturers, we must ask about concurrency, ask about thread pool, and ask about the meaning of some parameters of thread pool.

Then, some interviewers will ask some questions about the specific scenario of the thread pool.

Therefore, there may be a question in the interview mentioned above, which is a relatively advanced one in the Java interview.

I'm sure you must at least know what a thread pool is. To put it simply, it is to maintain a pool with many threads in it.

Then there is a task, and a thread acquires the task to execute. After the task is executed, the thread does not release it, but stays in the thread pool and waits for the next task.

One advantage is that you don't have to manually create and destroy threads frequently. After all, threads are heavy resources, and frequent creation and destruction are not good for system performance.

Let's take a look at the following figure to review the meaning of thread pools.

(2) how is the thread pool constructed?

So when you write code in Java, do you remember how thread pools are constructed?

Is it code like the following, for example, we construct a thread pool with a fixed number of threads:

So how on earth is the thread pool constructed inside Executors.newFixedThreadPool (10)?

In fact, it is very simple. If you open the JDK source code, you can see that the code is as follows:

To put it simply, a ThreadPoolExecutor object instance is constructed, which you roughly think of as a thread pool, passing in some parameters, which roughly include:

1 corePoolSize

2 maximumPoolSize

3 keepAliveTime

4 workQueue

Let's say that the number of threads passed in by our construction thread pool is 10, then here, corePoolSize and maximumSize are both 10, and the default is 0, and the workQueue is an unbounded LinkedBlockingQueue.

Next, let's take a specific look at how the thread pool works when some parameters are passed in to construct a thread pool.

(3) the operation principle of thread pool.

To put it simply, at the beginning, the thread pool is empty, that is, there is not a single thread, as shown in the following figure.

Then if you use the thread pool to submit a task and want it to be executed by a thread in the thread pool, as shown in the following code, submit a task:

At this time, the thread pool will first check to see if the number of threads in the pool has reached the number specified by corePoolSize.

Now the number of threads in the thread pool is 0, and then the corePoolSize is 10, so it must not have been reached, so it will directly create a thread in the thread pool and execute the task, as shown in the following figure.

Then, if the thread has finished processing a task, then the thread will not be destroyed at this time, it will always wait for the next submitted task.

So, how on earth did you wait?

Quite simply, the thread pool is paired with a workQueue, such as an unbounded LinkedBlockingQueue that can be put into tasks almost indefinitely.

Then after that thread finishes processing a task, it tries to get the task from the task queue in a blocking way. if the queue is empty, it will block and stay there until someone puts a task in the queue. He will get a task and continue to execute it, as shown in the following figure.

Then submit the task again, and the thread pool finds out as soon as it is judged, eh? It seems that the number of threads is only 1, which is completely smaller than corePoolSize (10), so continue to create a thread directly in the pool, then process the task, and then continue to try to get the task blocked from workQueue.

Repeat the above until there are 10 threads in the thread pool, reaching the number specified by corePoolSize, as shown in the figure below.

If you submit the task again at this time, he will suddenly find out, eh? No, there are already 10 threads in the thread pool, the same as the number of threads specified by corePoolSize.

So now, I don't need to create any extra threads, now all you have to do is submit the task and join the team directly into the workQueue.

At this time, the threads in the thread pool are blocking on the workQueue waiting for the task to be acquired. When a task comes in, it will wake up a thread to process the task, and then block the task on the workQueue to try to get the next task, as shown in the following figure.

Here we see that he is using an unbounded LinkedBlockingQueue, but what if he is using a bounded queue?

For example, if the queue is limited to a maximum of 10 tasks, then if the thread in the thread pool is too late to process the task, then the queue is suddenly full of 10 tasks.

At this point, there will be the failure of the task to join the queue because the queue is full and cannot be joined.

Then an attempt is made to create a thread in the thread pool again, and the thread is created until the number of threads in the thread pool reaches the number specified by maximumPoolSize.

Although the default number of corePoolSize and maximumPoolSize in the fixed thread pool is the same, can it be assumed that the number of maximumPoolSize is 20?

Then you will continue to create threads until the number of threads reaches 20, and then use the additional 10 threads created to continue working on the task when the queue is full.

The whole process, as shown in the following figure:

Then what happens if the queue is full and the number of threads in the thread pool reaches the number specified by maximumPoolSize, and you can't create additional threads?

The answer is: reject will be dropped, you will not be allowed to continue to submit the task, at this time the default is to throw an exception.

What about the additional threads created in the above figure that go beyond corePoolSize?

Once they have created it, they will find that the number of thread pools has exceeded that of corePoolSize, and they will try to wait for tasks in workQueue.

Once the time specified by keepAliveTime is exceeded and the task is not obtained, for example, keepAliveTime is 60 seconds, then if the task is not obtained in more than 60 seconds, it will be automatically released and the thread will be destroyed.

The whole process is shown in the following figure.

(4) memory surge caused by unbounded queues

Now that you understand how the thread pool works, this interview question can be easily solved.

Let's take the most commonly used fixed thread pool as an example, whose number of thread pools is fixed because he uses an almost unbounded LinkedBlockingQueue that can put tasks into the queue almost indefinitely.

So as long as the number of threads in the thread pool reaches the number specified by corePoolSize, the fixed number of threads is maintained.

Then, all the tasks are queued into the workQueue, and the thread gets the task from the workQueue to process.

This queue is almost never full, of course, because the default maximum number of tasks for LinkedBlockingQueue is Integer.MAX_VALUE, which is so large that it can be understood as infinite.

As long as the queue is dissatisfied, it doesn't matter to maximumPoolSize or keepAliveTime, because no more threads than corePoolSize will be created.

Again, let's give you a picture, and let's take a look at:

So at this point, in case each thread gets a task, it takes a particularly long time to handle it, which is excruciating. For example, what happens when it takes several hours to deal with a task?

Of course, there will be a constant backlog of more and more tasks in workQueue, constantly increasing.

This process will cause the machine's memory usage to soar continuously, and in the end, it may lead to JVM OOM in extreme cases, and the system will hang up.

So this is the thread pool operation principle that you need to know behind this interview question, as well as some problems that may be encountered, everyone should know well.

At this point, I believe you have a deeper understanding of "what happens to the thread pool using Java unbounded queues". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.