java - 如何改进使用 BasicDataSource 对象的 Java 应用程序？

Question

我们的服务器在工作中出现问题，我正在尝试了解发生了什么。它是一个在 linux 服务器上运行的 Java 应用程序，该应用程序从 TCP 套接字接收信息并对其进行分析，然后在分析后写入数据库。

有时数据包的数量太多，Java应用程序每秒需要多次写入数据库(如100到500次)。

我试着在我自己的电脑上重现这个问题，看看这个应用程序如何与 JProfiler 一起工作。

内存看起来一直在上升，是内存泄漏吗(抱歉我不是Java程序员，我是C++程序员)？

133 分钟后

158 分钟后

我有很多锁定线程，这是否意味着应用程序没有正确编程？

是否与数据库的连接过多(应用程序使用 BasicDataSource 类来使用连接池)？

该程序没有 FIFO 来管理从 TCP 端口输入的连续信息的数据库写入。我的问题是(请记住，我不是 Java 程序员，我不知道这是否是 Java 应用程序应该工作的方式，或者程序是否可以更有效地编程)

1. 您是否认为代码有问题，未正确管理数据库的写入、读取和更新并占用过多内存和 CPU 时间，还是它在 BasicDataSource 类中的工作方式？

2. 您认为我可以如何改进(如果您认为这是一个问题)这个问题，方法是创建一个 FIFO 并删除创建过多线程的代码部分？或者线程不是应用程序线程本身，而是 BasicDataSource 线程？

Answer 1

有几个方面需要深入研究，但首先我会尝试找出真正阻塞相关线程的原因。在查看应用程序之前，我也会假设所有内容，所以这是从应用程序开始的。

我知道图表显示可用内存，但它们只是时间点，所以我看不到趋势。 GC 日志记录可用，但我没有使用 JProfiler，所以我不确定如何在该工具中向您指出它。我知道在 DynaTrace 中我可以看到 GC 事件及其持续时间以及任何其他阻塞事件及其根本原因。如果这不可用，则可以使用命令行开关来记录 GC Activity 以查看其持续时间和频率。这是一个可能会阻塞的区域。

我还会查看您的池中有多少个连接。如果每秒有 100-500 个请求尝试写入，并且由于您没有足够的连接来处理它们而堆积起来，那么这也可能是一个问题。该图像显示了所有交易，但并未说明池大小。事务阻塞而无处可去也可能导致您的内存跳跃。

还有另一面，您的数据库无法处理流量并被锁定，这也是阻止连接的原因，因此您需要监控这方面的事情，看看这是否是可能的原因的阻塞。

阻塞也有可能是由于正在运行的 SQL、等待释放页面锁等造成的。

有很多方面需要查看，但我会从应用程序开始逐层处理并逐层验证。