随着 T4CPreparedStatement 的增加，内存泄漏 [英] Memory leak with increasing T4CPreparedStatement

问题描述

我们有一个使用 hibernate 4.2.22 (JBoss 6.4.7) 的应用程序.在我们的代码中，我们不使用任何 PreparedStatements，每个 db-question 都由 hibernate 处理.

We got an app that uses hibernate 4.2.22 (JBoss 6.4.7). In our code we do not use any PreparedStatements, every db-question is handled by hibernate.

但是在性能测试期间，我们得到了 oom.其原因似乎是我们猜测有大量 oracle.jdbc.driver.T4CPreparedStatement 实例是从休眠中创建的.即使我们从 VisualVM 执行 GC，它们仍然存在并且在我们运行测试时会增加.

But during performance test we get oom. The reason for that seems to be an very big amount of instances of oracle.jdbc.driver.T4CPreparedStatement that we guess are created from hibernate. Even if we perform GC from VisualVM they are still present and increases when we run our test.

你们怎么看，有没有办法解决这个问题?

What do you think guys, is there a way to solve this?

最好的问候弗雷德里克

推荐答案

我想我们已经解决了.我们在 JBoss 中配置了我们的数据源，如下所示:

I think we solved it. We had configure our datasource in JBoss like this:

 <pool>
  <min-pool-size>200</min-pool-size>
  <max-pool-size>400</max-pool-size>
 </pool>
..
<statement>
  <prepared-statement-cache-size>100</prepared-statement-cache-size>
  <share-prepared-statements>true</share-prepared-statements>
 </statement>

现在我们把它改成

<statement>
 <prepared-statement-cache-size>5</prepared-statement-cache-size>
 <share-prepared-statements>true</share-prepared-statements>
</statement>

现在 GC 似乎运行良好.我猜准备好的语句池太大了.我猜我们有 400*100，现在我们有 400*5.

And now the GC seems to work well. I guess the pool for prepared statements was too big. I guess it we had 400*100, now we have 400*5.

欢迎所有评论.此致弗雷德里克

All comments are welcome. Best regards Fredrik

这篇关于随着 T4CPreparedStatement 的增加，内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！