Cómo evitar problemas de GeneratedSerializationConstructorAccessor?

Tenemos una aplicación Java que recibe solicitudes SOAP, y después de muchas solicitudes notamos que el GC detiene al mundo para descargar muchas clases GeneratedSerializationConstructorAccessor. Este es un gran impacto en el rendimiento.Cómo evitar problemas de GeneratedSerializationConstructorAccessor?

¿Alguien sabe cómo evitar esto o, al menos, reducir significativamente el recuento de clases GeneratedSerializationConstructorAccessor creadas?

Fuente

2010-06-04 james

¿Por qué está etiquetado gcc (Gnu Compiler Collection)? ¿Quisiste etiquetarlo gc (recolector de basura)? ¿Estás usando gcj (compilador Gnu para Java)? –

Creo que fue un error tipográfico, lo cambio a 'gc' – OscarRyz

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

Estas clases son parte del mecanismo reflexión. Dado que alrededor de Java 1.3 reflexión ha sido implementado mediante la generación de clases a realizar el acceso. Es mucho más rápido el uso de , pero lleva más tiempo crearlo y altera la generación permanente.

serialización los utiliza para leer/escribir campos, ejecutar métodos (readObject, writeObject, readObjectNoData, readResolve) y llamar a la no serialisable clase base constructor (este último código no es verificable ).

Parece que solo se usan transitoriamente para serializar/deserializar una clase de objeto determinada. Como señala el artículo, es probable que se lleven a cabo con SoftReferences, así que asegúrese de que su aplicación tenga mucha memoria, y se recuperarán con menos frecuencia.

Sorprendentemente, no parece haber otra solución.

Fuente

2010-06-04 01:55:37 mdma

Utilice una de las opciones:

-Dsun.reflect.inflationThreshold=30

Aumenta el número de llamadas a través de un constructor/Método/Campo antes de un descriptor de acceso nativo será "inflada" a un descriptor de acceso generada. El valor predeterminado es 15.

-Dsun.reflect.inflationThreshold=0

Desactiva la inflación por completo. Curiosamente, esta opción no parece afectar a los constructores, pero funciona para los métodos.

Puede probar las opciones con una sencilla aplicación de prueba:

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

Editar (29-Dec-2013): La opción -Dsun.reflect.noInflation=true desactiva el mecanismo de inflado y en su lugar inmediatamente utiliza descriptores de acceso generada, por lo que don no quiero esa opción

Fuente

2010-06-04 03:36:51

De hecho, establecer noInflation en true hará que todo el acceso se realice mediante la generación de código byte. Desea establecer el umbral en cero o menos. –

@raphw ¡Tienes razón, gracias por corregir mi desinformación! He editado la publicación con tu sugerencia. –

[...] notamos que el GC detiene el mundo para descargar muchas clases GeneratedSerializationConstructorAccessor. Este es un gran impacto de rendimiento.

Como es imposible de evitar si la aplicación está utilizando la reflexión, es posible que intente utilizar CMS garbage collector para minimizar el impacto de la parada GC-el-mundo.

Fuente

2010-06-30 08:35:46 fglez

Cómo evitar problemas de GeneratedSerializationConstructorAccessor?

Respuesta

Cuestiones relacionadas