Comment éviter les problèmes GeneratedSerializationConstructorAccessor?

Nous avons une application Java qui reçoit des demandes SOAP, et après beaucoup de demandes, nous remarquons que le GC arrête le monde pour décharger beaucoup de classes GeneratedSerializationConstructorAccessor. C'est un gros impact sur les performances.Comment éviter les problèmes GeneratedSerializationConstructorAccessor?

Est-ce que quelqu'un sait comment éviter cela ou du moins réduire considérablement le nombre de classes GeneratedSerializationConstructorAccessor créées?

Source

2010-06-04 james

Pourquoi est-ce marqué gcc (Gnu Compiler Collection)? Vouliez-vous dire gc (garbage collector)? Utilisez-vous gcj (Gnu Compiler for Java)? –

Je pense que c'était une faute de frappe, je le change en 'gc' – OscarRyz

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

Ces cours font partie du mécanisme de réflexion . Depuis environ Java 1.3 réflexion a été mis en œuvre en générant des classes à effectuer l'accès. Il est beaucoup plus rapide, mais prend plus de temps à créer et bouleverse la génération permanente.

sérialisation les utilise pour la lecture/écriture champs, exécuter des méthodes (readObject, writeObject, readObjectNoData, readResolve) et appeler le constructeur classe de base non serialisable (ce dernier code n'est pas vérifiable).

Il semble qu'ils ne soient utilisés que de manière transitoire pour sérialiser/désérialiser une classe d'objet donnée. Comme le souligne l'article, ceux-ci sont probablement conservés à l'aide de SoftReferences, alors assurez-vous que votre application dispose de suffisamment de mémoire et que celles-ci seront récupérées moins souvent. De manière surprenante, il ne semble pas y avoir d'autre solution.

Source

2010-06-04 01:55:37 mdma

Utilisez l'une des options suivantes:

-Dsun.reflect.inflationThreshold=30

Augmente le nombre d'appels par un constructeur/Méthode/terrain avant un accesseur natif sera « gonflé » à un accesseur généré. La valeur par défaut est 15.

-Dsun.reflect.inflationThreshold=0

Désactive complètement l'inflation. Fait intéressant, cette option ne semble pas affecter les constructeurs, mais elle fonctionne pour les méthodes.

Vous pouvez tester les options avec une application de test simple:

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): L'option -Dsun.reflect.noInflation=true désactive le mécanisme de l'inflation et au lieu immédiatement utilise généré accesseurs, de sorte que vous don Je ne veux pas cette option.

Source

2010-06-04 03:36:51

En fait, en définissant noInflation à true, tous les accès seront effectués par génération de code octet. Vous voulez définir le seuil à zéro ou moins. –

@raphw Vous avez raison, merci de corriger ma désinformation! J'ai modifié le post avec votre suggestion. –

[...] on remarque que le GC arrête le monde pour décharger beaucoup de cours GeneratedSerializationConstructorAccessor. C'est une grande performance impact.

Comme il est impossible d'éviter si votre application utilise la réflexion, vous pouvez essayer d'utiliser CMS garbage collector pour minimiser l'impact de l'arrêt du monde GC.

Source

2010-06-30 08:35:46 fglez

Comment éviter les problèmes GeneratedSerializationConstructorAccessor?

Répondre

Questions connexes