How to avoid GeneratedSerializationConstructorAccessor problems?

We have a Java App that receives SOAP requests, and after a lot of requests we notice that the GC stops the world开发者_开发知识库 to unload a lot of GeneratedSerializationConstructorAccessor classes. This is a big performance impact.

Does anyone know how to avoid this or at least significantly reduce the count of GeneratedSerializationConstructorAccessor classes created?

---

Use one of the options:

-Dsun.reflect.inflationThreshold=30

Increases the number of calls through a Constructor/Method/Field before a native accessor will be "inflated" to a generated accessor. The default is 15.

-Dsun.reflect.inflationThreshold=0

Disables inflation altogether. Interestingly, this option does not seem to affect constructors, but it does work for methods.

You can test the options with a simple test app:

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();
  }
}

Edit (29-Dec-2013): The -Dsun.reflect.noInflation=true option disables the inflation mechanism and instead immediately uses generated accessors, so you don't want that option.

---

[...] we notice that the GC stops the world to unload a lot of GeneratedSerializationConstructorAccessor classes. This is a big performance impact.

As it is impossible to avoid if your application is using reflection, you may try using CMS garbage collector to minimize the impact of the stop-the-world GC.

---

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

These classes are part of the reflection mechanism. Since around Java 1.3 reflection has been implemented by generating classes to perform the access. It's much faster use, but takes longer to create and upsets the permanent generation.

Serialisation uses them to read/write fields, execute methods (readObject, writeObject, readObjectNoData, readResolve) and call the non-serialisable base class constructor (this last code is not verifiable).

It appears they're only used transiently to serialize/deserialize a given class of object. As the article points out, these are probably held using SoftReferences, so ensure that your app has plenty of memory, and these will be reclaimed less often.

Surprisingly, there doesn't appear to be any other solution.