JSF通过EL和复合组件泄漏内存

mab*_*abn 7 jsf memory-leaks el composite-component

注意:我使用的是mojarra 2.1.20和丰富的面孔4.2.2.

我已经分析了一个堆转储,我注意到EL表达式驻留在会话中的LRUMap中.有谁知道为什么以及如何避免它?

我遇到的问题与包含以下行的复合组件有关:

  <rich:select ... valueChangeListener="#{cc.listValuesChangeListener}"
Run Code Online (Sandbox Code Playgroud)

使用支持bean my.package.MultiComboSelection.显然my.package.MultiComboSelection有一个名为listValuesChangeListener的方法.

我看到的问题是LRUMap包含ContextualCompositeMethodExpression(上面的valueChangeListener表达式的表示),cc属性引用MultiComboSelection.MultiComboSelection扩展了UINamingContainer,因此具有父/子属性 - 引用了组件树.

结果是16MB的内存不能被垃圾收集,因为有一个参考链:

session-> LRUMap-> ContextualCompositeMethodExpression-> MultiComboSelection-> parent和16MB

问题是 - 为什么会发生这种情况以及如何解决或解决它?

Class Name                                                                                   | Shallow Heap | Retained Heap | Retained Heap
--------------------------------------------------------------------------------------------------------------------------------------------
my.package.MultiComboSelection @ 0x78dc2bd50                                                 |           96 |    16 466 272 |    16 466 272
|- component javax.faces.component.UIComponentBase$FacetsMap @ 0x78dbbbd58                   |           48 |           128 |              
|- parent javax.faces.component.UIPanel @ 0x78dbbbdd8                                        |           88 |           760 |              
|- cc com.sun.faces.facelets.el.ContextualCompositeMethodExpression @ 0x78dc2bce0            |           32 |    16 466 384 |              
|  |- [0] java.lang.Object[2] @ 0x78dc2bc90                                                  |           24 |    16 466 464 |              
|  |  '- [0] java.lang.Object[1] @ 0x78dc2bc78                                               |           24 |    16 466 488 |              
|  |     '- [0] java.lang.Object[5] @ 0x78dc2bc20                                            |           40 |    16 466 576 |              
|  |        '- [0] java.lang.Object[2] @ 0x78dc2bc08                                         |           24 |    16 466 600 |              
|  |           '- [0] java.lang.Object[4] @ 0x78dc2bbe8                                      |           32 |    16 466 632 |              
|  |              '- value java.util.HashMap$Entry @ 0x78dc2bb40                             |           32 |    16 466 800 |              
|  |                 '- [1579] java.util.HashMap$Entry[2048] @ 0x78dbf61b8                   |        8 208 |    33 552 536 |              
|  |                    '- table java.util.HashMap @ 0x78dbb6860                             |           48 |    33 552 584 |              
|  |                       '- [1] java.lang.Object[2] @ 0x78ad95340                          |           24 |    33 552 608 |              
|  |                          '- value java.util.LinkedHashMap$Entry @ 0x78ad952c0           |           40 |    33 552 736 |              
|  |                             |- after, before java.util.LinkedHashMap$Entry @ 0x78acbe6a0|           40 |            40 |              
|  |                             |- [0] java.util.HashMap$Entry[2] @ 0x78ad952a8             |           24 |            24 |              
|  |                             |  '- table com.sun.faces.util.LRUMap @ 0x78ad95270         |           56 |    33 552 856 |              
--------------------------------------------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)

Bal*_*usC 6

ContextualCompositeMethodExpression所引用整个复合材料部件的实例变量作为一个修复的后果发出1462.用户已经报告了与1940年问题完全相同的内存泄漏问题.然后,实例变量被标记transient为修复问题1943的结果.然而,问题1940由于某种原因被标记为1943年的重复.两个用户在1940年问题的底部正确地评论了你的问题,内存泄漏问题仍然存在,但我没有看到任何新的问题报告相关之后的那个.当复合组件包含任何方法表达式(如值更改侦听器)时,问题确实只会出现.

从理论上讲,这个问题可以通过告诉Mojarra在会话中序列化视图状态而不是保持对视图状态的引用来解决.随着实例变量的标记transient,它将被绕过.您可以通过以下上下文参数来实现web.xml:

<context-param>
    <param-name>com.sun.faces.serializeServerState</param-name>
    <param-value>true</param-value>
</context-param>
Run Code Online (Sandbox Code Playgroud)

再次,理论上; 我没有测试过.

您可能也想尝试MyFaces,我不能说它会解决这个问题,但我知道MyFaces 2.x到目前为止通常比Mojarra更谨慎,因为状态管理,内存使用和性能.

同时,我强烈建议为Mojarra创建一个新问题,引用问题1940,这个Stack Overflow问题和你的发现.在视图状态中引用UI组件绝对不对.UI组件实例本质上是请求作用域,而不是视图作用域.


更新:重新报告为3198问题,在Mojarra 2.2.8和Mojarra 2.1.29中按照问题3544修复.因此,如果您升级到至少那些版本,那么当您不使用com.sun.faces.serializeServerState=true(或javax.faces.SERIALIZE_SERVER_STATE=true根据JSF 2.2)时,应修复此内存泄漏.