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

我们在服务器上有一个问题，我正试图理解发生了什么。这是一个运行在Linux服务器上的Java应用程序，应用程序接收来自TCP套接字的信息并分析它们并在分析后写入数据库。

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

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

内存看起来总是上升，是内存泄漏（抱歉，我不是一个Java程序员，我是C ++程序员）？

在这里输入图像说明

133分钟后在这里输入图像说明

158分钟后在这里输入图像说明

我有很多locking的线程，这是否意味着应用程序没有正确编程？在这里输入图像说明

连接数据库是否太多（应用程序使用BasicDataSource类来使用连接池）？在这里输入图像说明

该程序没有FIFO来pipe理数据库写入从TCP端口input的连续信息。我的问题是（记住，我不是一个Java程序员，我不知道这是一个Java应用程序应该工作还是程序可以编程更有效的方式）

你认为那些不正确地pipe理数据库上的写，读，更新的代码有什么问题，并且会占用太多的内存和CPU时间，还是它在BasicDataSource类中的工作方式？
你觉得我可以通过创build一个FIFO并删除创build太multithreading的代码部分来改进它（如果你认为这是一个问题），你怎么看？或者线程不是自己的应用程序线程，这就是BasicDataSource线程？

有几个领域需要深入研究，但首先我会尝试找到实际上阻塞有问题的线程。在应用程序被查看之前，我会假设一切，所以这是从应用程序下来。

我知道这些图表显示了免费的记忆，但他们只是时间点，所以我看不到一个趋势。 GC日志记录是可用的，我还没有使用JProfiler很多，所以我不知道如何指向你在这个工具。我知道在DynaTrace中，我可以看到GC事件及其持续时间以及其他阻塞事件及其根源。如果这不可用，则有命令行开关记录GC活动以查看其持续时间和频率。这是一个可以阻止的领域。

我也会看看你在游泳池里有多少连接。如果有100-500个请求/秒试图写入，并且因为没有足够的连接来工作而堆叠起来，那么这也可能是一个问题。该图显示了所有的交易，但不说池的大小。阻止无处可去的事务也可能导致你的内存跳转。

还有另外一个方面，你的数据库不能处理流量，并且被挂住了，这也是阻塞连接的原因，所以你需要监视那些事情的结束，看看是否可能导致阻塞。

也有可能从运行的SQL中发生阻塞，等待页面锁被释放等等。

很多地方看，但我会解决和验证一个层，一次开始与应用程序和工作。