由于接收超时和任务执行器失调而导致内存泄漏 [英] Memory leak because of receive timeout and task executor out of tune conf

问题描述

我正在阅读 spring 集成参考文档和第 10.1.8 节 异步轮询 它写道，失调的 conf 会导致内存泄漏.

I'm going through spring integration reference document and in section 10.1.8 Asynchronous Polling it's written that out of tune conf can cause memory leak.

根据下面的文档是不合时宜的 conf :

As per docs below is out of tune conf :

<int:channel id="publishChannel">
    <int:queue />
</int:channel>
<int:service-activator input-channel="publishChannel" ref="myService">
    <int:poller receive-timeout="5000" task-executor="taskExecutor" fixed-rate="50" />
</int:service-activator>
<task:executor id="taskExecutor" pool-size="20" />

我在理解这部分时遇到了麻烦，因为它写的是每秒将执行 4 个线程，因为每个线程将等待 250 毫秒，并且任务将以每秒 20 个的速度添加.

I'm having trouble in understanding this section as it's written 4 threads will be executed every second as each thread will wait for 250 ms and task will be added at rate of 20 per second.

任务执行器不应该只分配 1 个线程来等待传入的消息，并且应该启动最大线程以防队列中有足够的任务吗?另外，如果任务耗时超过 250 毫秒，为什么每秒只有 4 个线程会执行?

Shouldn't task executor assign only 1 thread to wait for incoming message and should start max threads in case there's sufficient task in queue? Also why only 4 thread will execute per second what if task takes more than 250 ms?

如果它太简单而我遗漏了一些微不足道的东西，我们深表歉意.

Apologies if it's too simple and I'm missing something trivial.

推荐答案

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

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.

这篇关于由于接收超时和任务执行器失调而导致内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！