如何避免GenerateSerializationConstructorAccessor问题？

Question

我们有一个接收 SOAP 请求的 Java 应用程序，在收到大量请求后，我们注意到 GC 停止了卸载大量的 generatedSerializationConstructorAccessor 类。这是一个很大的性能影响。

有谁知道如何避免这种情况或至少显着减少创建的GenerateSerializationConstructorAccessor类的数量？

Answer 1

[...] 我们注意到 GC 停止了卸载大量内容
生成的SerializationConstructorAccessor 类。这是一场盛大的表演
影响。

如果您的应用程序使用反射，这是不可避免的，您可以尝试使用 CMS 垃圾收集器，以尽量减少 stop-the-world GC 的影响。

Answer 2

来自 http://coding.derkeiler .com/Archive/Java/comp.lang.java.programmer/2006-11/msg00122.html

这些类是
反射机制。自从大约
Java 1.3 反射已
通过生成类来实现
执行访问。速度快多了
使用，但需要更长的时间来创建和
让永久的一代感到不安。

序列化使用它们来读/写
字段、执行方法（readObject、
写对象，读对象无数据，
readResolve）并调用
不可序列化的基类
构造函数（最后一个代码不是
可验证）。

看来它们只是暂时用于序列化/反序列化给定类的对象。正如文章指出的，这些可能是使用 SoftReferences 保存的，因此请确保您的应用程序有足够的内存，并且这些内存的回收频率会降低。

令人惊讶的是，似乎没有任何其他解决方案。

Answer 3

使用以下选项之一：

-Dsun.reflect.inflationThreshold=30

在本机访问器“膨胀”为生成的访问器之前，增加通过构造函数/方法/字段的调用次数。默认值为 15。

-Dsun.reflect.inflationThreshold=0

完全禁用通货膨胀。有趣的是，这个选项似乎不会影响构造函数，但它确实适用于方法。

您可以使用简单的测试应用程序来测试这些选项：

public class a {
  public static void main(String[] args) throws Exception {
    for (int i = 0; i < 20; i++) {
      a.class.getDeclaredConstructor(null).newInstance(null);
    }
  }

  private static int x;
  public a() {
    new Throwable("" + x++).printStackTrace();
  }
}

编辑 (2013 年 12 月 29 日)： -Dsun.reflect.noInflation=true 选项禁用通货膨胀机制，取而代之的是立即使用生成的访问器，因此您不需要该选项。