Do not solve the improper delay, be careful that your memory is blown up

Abstract: This is an improper delay found in the specific code, which may burst the memory in extreme cases.

This article is shared from the HUAWEI cloud community " thread improper use delay problem ", the original author: technical torchbearer.

background

This is a problem of improper delay found in the specific code, which may burst the memory in extreme cases.

Code DevLicenseServiceRoaDelegateImpl.java

definition:

use:

signalRefreshHelp definition

The biggest problem with this code is the improper use of the delay algorithm, which in extreme cases will cause the memory to skyrocket and seriously affect the performance of the service program.

Do not use sleep to achieve delay

Using sleep to achieve delay seems very intuitive, but this must be particularly careful in high-concurrency, multi-request, long-running service programs. This is because a very important indicator for measuring the performance of a service program is QPS, which is the processing capacity of the service program. Generally, the larger the better; the total concurrency of the service program is equal to the qps of each thread; the QPS of a single thread = 1000 milliseconds/ (Milliseconds to process a request); so the QPS of the thread above is <= 1000/10000 = 0.1 (because the thread sleeps for 10000 milliseconds).

The processing logic here is wrong! There are also serious performance hazards, but fortunately, there are not many requests to call this api, which did not cause serious problems.

The developer’s intention is to delay the execution of a task for 10 seconds after creating a task. The processing sequence diagram is as follows

If the time points t1 & t2 are very close, the threads are also very close when executing job1 & job2.

But the actual situation becomes:

Even if the time to create job1 & job2 is very close, the execution time of job2 will be 10s longer than expected; the more tasks that are continuously submitted, the easier it is to accumulate. These accumulated tasks are stored in the blocking queue and will not be deleted until the processing is completed; if If there are many such requests, it is easy to cause the memory to burst.

solution

Choose the appropriate data structure, the default thread pool associated queue is LinkedBlockingQueue, there is no delay control, you can use DelayQueue