我注意到我的应用程序很慢。我决定分析GC日志和堆转储。我突然得到了这个:
一些JRVerticalFiller占用了3.4Gb的4Gb堆内存。 它从TaskThread开始,它持有JRVerticalFiller,一个持有JasperPrint,来自JasperPrint手 - Collections.synchronizedList(pages),这些对象是JRTemplatePrintText。
这是从TaskThread到Object []的gc路径(ArrayList中的这个Object [])
注意:我正在使用JRGzipVizualizer。也许这就是原因,我不确定。据我所知,它会在内存中生成并保存报告。
实际上我并不理解为什么TaskThread还活着以及为什么创建了这么多对象。 它看起来像是内存泄漏。
***************** 编辑 *******************
实际上在调试JasperReport之后JRVerticalFiller我找到了方法
protected SavePoint fillColumnBand(JRFillBand band, byte evaluation)
....
while (band.willOverflow()){
fillColumnBreak(evaluation, evaluation);
printBand = band.fill(columnFooterOffsetY - offsetY);
fillBand(printBand);
offsetY += printBand.getHeight();
}
....
我在band.willOverflow()中得到了无限循环。它总是返回true。
相关问题 - Jasper Reports : sub-reports are causing an infinite loop
有一种观点认为问题出在isPrintWhenDetailOverflows标志中,它应该是false。实际上在我的情况下,我把它设置为假,它的工作原理。 但不幸的是,这是一个魔法,我不明白如何重现它,以及 它只依赖于isPrintWhenDetailOverflows标志吗?我有很多地方这个国旗是真的,但现在我正在研究这些情况之间的区别。