线程池的设计模式

Question

我目前有一个具有大量线程的应用程序，这使得该应用程序非常大。每个线程都是长时间运行的，基本上是一个无限循环，轮询新的电子邮件，然后处理它们。每个线程保持一个SSL连接，这就是线程在应用程序中工作良好的原因。

我想使用线程池。最简单的方法是只固定线程的数量，然后为每个线程添加10个用户，但即使在这一点上，它似乎也不能像1个用户/线程那样均匀地平衡工作，因为每个循环的处理时间都相当长。另外，这实际上不是一个线程池。

我的问题是-这里合适的设计模式是什么(因为它肯定比我上面写的更智能)，有没有一个C++库可以很好地处理这个问题？向我推荐Java实用程序也会很有帮助，因为根据我的经验，从Java实用程序中找出设计模式非常容易。

Answer 1

一个用户/线程可能是一个很好的起点。任何阻塞或可以阻塞的东西都需要在它自己的线程中运行，以避免被其他执行代码阻塞或被阻塞。如果电子邮件的实际处理将直接运行，则可以将其放在"runnable“中(使用Java术语)，并提交到线程池中。Java术语应该是ThreadPoolExecutor，您自己编写一个简单的术语并不难。您可能希望为每个可能的CPU核心分配一个线程，以便从您的计算机中获得最多的工作。

如果每封电子邮件的工作量不是很大，那么跳过线程池，只在阅读器线程上完成工作可能会更简单、更快。你已经付出了运行它的成本，你也可以尽你所能地完成所有的工作。

在另一个极端，如果处理一封电子邮件涉及阻塞或被阻塞，您可能希望为每个电子邮件启动一个新线程。你可能会得到很多线程，但它会让你的计算机得到最大的工作量。你不想在CPU使用率只有5%的情况下落后于电子邮件。

Answer 2

我在中间放了一个BlockingDeque，在后端放了一个线程池消费者。这将电子邮件生产者与消费者解耦，并允许您在后端汇集消费者。看看这个：

Producer Consumer Example

Answer 3

有许多模式可以解决这个问题，但做出决定的关键点是理解模式的后果。ACE website有一些文章介绍了一些可能适合的并发模式，比如Active Object、Proactor和Reactor。示例是C++，但是如果您追求自己的实现，也有一些图表和描述会很有帮助。

proactor可以提供优雅的解决方案，也可以作为另一种模式的基础。对于C++实现，我推荐使用boost::asio库：

• 有相当好的文档和示例。
• SSL支持。
• HTTP Server 3示例显示了如何将boost::asio用于线程池。

如果您不想依赖于boost，那么asio库也可以单独打包为here。有关更多模式和信息，请参阅this一书。