Wie vermeidet man GeneratedSerializationConstructorAccessor Probleme?

Question

Wir haben eine Java-App, die SOAP-Anfragen empfängt, und nach vielen Anfragen stellen wir fest, dass der GC die Welt davon abhält, viele GeneratedSerializationConstructorAccessor-Klassen zu entladen. Dies ist eine große Auswirkung auf die Leistung.

Kann jemand dies vermeiden oder zumindest die Anzahl der generiertenSerializationConstructorAccessor-Klassen erheblich reduzieren?

Answer 1

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

Diese Klassen sind Teil des Reflexionsmechanismus. Seit etwa Java 1.3 Reflexion wurde implementiert, indem Klassen generieren den Zugriff durchführen. Es ist viel schneller verwenden, dauert aber länger zu erstellen und stört die permanente Generation.

Serialisierung verwendet sie Felder lesen/schreiben, ausführen Methoden (readObject-, write, readObjectNoData, readResolve) und rufen Sie die nicht-serialisable Basisklasse Konstruktor (dieser letzte Code ist nicht überprüfbar).

Es scheint, dass sie nur vorübergehend verwendet werden, um eine bestimmte Klasse von Objekten zu serialisieren/deserialisieren. Wie der Artikel zeigt, werden diese wahrscheinlich mithilfe von SoftReferences gehalten. Stellen Sie daher sicher, dass Ihre App über ausreichend Arbeitsspeicher verfügt und diese seltener wiederhergestellt werden.

Überraschenderweise scheint es keine andere Lösung zu geben.

Answer 2

Verwenden Sie eine der Optionen:

-Dsun.reflect.inflationThreshold=30 

Erhöht die Anzahl der Anrufe durch eine Constructor/Methode/Feld vor einem nativen Accessor wird „aufgeblasen“ zu einem generierten Accessor sein. Der Standardwert ist 15.

-Dsun.reflect.inflationThreshold=0 

Deaktiviert die Inflation insgesamt. Interessanterweise scheint diese Option keine Konstruktoren zu beeinflussen, aber sie funktioniert für Methoden.

können Sie testen Sie die Optionen mit einem einfachen 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): Die -Dsun.reflect.noInflation=true Option deaktiviert die Inflation Mechanismus und stattdessen sofort verwendet Accessoren erzeugt, so dass Sie don Ich will diese Option nicht.

Answer 3

[...] wir bemerken, dass der GC die Welt stoppt, um eine Menge GeneratedSerializationConstructorAccessor-Klassen zu entladen. Dies ist eine große Leistung Auswirkungen.

Da es unmöglich ist, zu vermeiden, wenn Ihre Anwendung Reflektion verwenden, können Sie mit CMS garbage collector versuchen, die Auswirkungen des Stop-the-World-GC zu minimieren.