且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

由于接收超时和任务执行器失调而导致内存泄漏

更新时间:2023-10-24 18:28:22

带有 ***任务队列.这是默认的.

The <task:executor id="taskExecutor" pool-size="20" /> is with an unbounded task queue. This is that default one.

task-executor="taskExecutor" fixed-rate="50" 意味着不要阻塞调度程序的线程,调度程序每 50 毫秒开始一个新的轮询!它的发生确实独立于 publishChannel 内容.我的意思是新任务总是放在 taskExecutor 队列中.

The task-executor="taskExecutor" fixed-rate="50" means don't block scheduler's thread and scheduler starts a new poll every 50 milliseconds! And it happens indeed independently of the publishChannel content. I mean the new task is always placed into taskExecutor queue.

如果下游进程真的足够长,执行器的所有 20 个线程都会很忙,并且任务的内部队列将会增长.这就是内存泄漏最严重的地方.

If the process downstream is really long enough, all 20 threads of the executor are going to be busy and that internal queue for tasks is going to grow. That's where memory leak comes to the top.

1 秒/50 毫秒 = 每秒 20 个任务.

1 second/ 50 millis = 20 tasks per second.

如果publishChannel 中没有消息,我会说任务执行器中的所有线程都将忙于等待 5 秒超时.那么,任务的费率是多少?20 个活动任务/等待完成的 5000 毫秒 = 每秒 4 个.

If there are no messages in the publishChannel, I would say all the threads in the task executor are going to be busy waiting for 5 seconds timeout. So, what is the rate for tasks? 20 active tasks / 5000 millis to wait for their finish = 4 per second.

这个故事不是关于 4 个线程,而是在值得的情况下我们能够以多快的速度排空任务队列.

The story is not about 4 threads, it is indeed how fast we are able to drain task queue in the worth case.