这些事情显然需要仔细检查和代码的可用性来彻底分析并给出好的建议。然而，这并不总是可行的，我希望可以根据我在下面提供的信息为我提供好的提示。
我有一个服务器应用程序，它使用监听器线程来监听传入数据。传入的数据被解释为特定于应用程序的消息，然后这些消息会引发事件。
到那时为止，我真的无法控制事情的完成方式。
因为这是一个遗留应用程序，所以这些事件以前由同一个监听器线程(主要是单线程应用程序)处理。事件被发送到黑盒，结果应该写入磁盘。
为了提高吞吐量，我想使用线程池来处理事件。这个想法是监听线程可以在每次创建事件时生成新任务，并且线程将负责黑盒调用。最后，我有一个后台线程执行写入磁盘。
仅使用之前的设置和后台编写器，一切正常，吞吐量是之前的约 1.6 倍。
当我添加线程池时，性能会下降。一开始，一切似乎都运行顺利，但过了一会儿一切都非常缓慢，最后我得到了 OutOfMemoryExceptions。奇怪的是，当我每次将任务添加到池中时打印 Activity 线程数(以及有关排队的任务数等信息)时，线程池似乎没有问题跟上生产者(监听线程)。
使用 top -H 检查 CPU 使用情况，一开始它分布得相当均匀，但最后工作线程几乎不活跃，只有监听器线程处于 Activity 状态。然而它似乎并没有提交更多任务......
任何人都可以假设这些症状的原因吗？您是否认为遗留代码中的某些东西(我无法控制)更有可能在添加多个线程时变坏？内存不足问题应该是因为某处的某个队列变得太大，但由于线程池几乎从不包含排队的任务，所以不可能是这样。
欢迎任何想法。特别是关于如何更有效地诊断这种情况的想法。我怎样才能更好地了解我的线程正在做什么等等。
谢谢。
最佳答案
减速然后内存不足意味着内存泄漏。
所以我会首先使用一些 Java 内存分析器工具来确定是否存在泄漏以及泄漏了什么。有时你很幸运，泄露的对象是众所周知的，并且很清楚谁在坚持他们不应该坚持的事情。
关于Java内存使用/线程池性能问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6832351/