java - 我如何利用集群环境的强大功能来处理 I/O 绑定(bind)作业的线程池？

Question

我开发了一个基于 JAVA 的服务器，该服务器具有一个线程池，该线程池会根据客户端请求率动态增长。该策略称为 FBOS(基于频率的优化策略)FBOS for Thread pool System 。

例如，如果请求率为每秒 5 个请求，那么我的线程池将有 5 个线程来服务客户端的请求。客户端请求是 1 秒的 I/O 绑定(bind)作业，即每个请求都是一个可运行的java对象，它有一个sleep()方法来模拟I/O操作。

如果客户端请求率为每秒 10 个请求，那么我的线程池中将有 10 个线程来处理客户端。每个Thread都有一个内部定时器对象，当其对应的线程空闲时，定时器对象被激活，当其空闲时间达到5秒时，定时器将从线程池中删除其对应的线程，以动态收缩线程池。

我的策略对于短 I/O 强度运行良好。我的服务器对于小请求率运行良好，但对于大请求率，我的线程池内部有大量线程。例如，如果请求率为每秒 100 个请求，那么我的线程池中将有 100 个线程。

现在我脑子里有3个问题

(1) 对于大请求率，使用此策略是否会面临内存泄漏？

(2) 操作系统或 JVM 是否会在大请求速率下面临过多的线程管理开销，从而降低系统速度

(3)最后一个也是非常重要的问题是，我很好奇在集群环境中实现我的线程池(我是集群中的DUMMY)。

我只是想听取大家的建议，了解集群环境如何在仅针对 I/O 绑定(bind)作业的基于频率的线程池场景中为我带来更多好处。也就是说，集群环境可以让我受益于使用其他系统(节点)的内存吗？

Answer 1

最简单的解决方案是使用缓存线程池，请参阅Executors 我建议您首先尝试这个。这将创建一次需要的线程数。对于 IO 绑定(bind)请求，单台机器可以轻松扩展到 1000 个线程，而不需要额外的服务器。

Can i face memory leaks using this strategy, for large request rate?

不，每秒 100 个并不是特别高。如果您每秒通话超过 10,000 次，则可能有问题(或需要另一台服务器)

Can OS or JVM face excessive Thread management overhead on large request rate that will slow down the system

是的，我的经验法则是 10,000 个线程会浪费大约 1 个 cpu 开销。

Last and very important question is that ,I am very curious to implement my thread Pool in a clustered environment(I am DUMMY in clustering).

鉴于您看起来最多使用一台机器的 1%，我不会担心使用多台机器来执行 IO。您很可能想要处理结果，但如果没有更多信息，您无法判断更多机器是否有帮助。

can a clustering environment give me benefit of using memories of other systems(nodes)?

如果您需要它，它可以提供帮助；如果您不需要它，它可能会增加您不需要的复杂性。

我建议你从一个真正的问题开始，寻找解决方案来解决它，而不是从一个很酷的解决方案开始，然后尝试找到一个可以解决的问题。