¿Usar el espacio PermGen o el método de prácticas internas de "rodar mi propio yo"?

Question

Estoy escribiendo un códec para procesar los mensajes enviados a través de TCP utilizando un protocolo de cable a medida. Durante el proceso de decodificación creo un número de String s, BigDecimal sy fechas. Los patrones de acceso de cliente-servidor significan que es común para el cliente para emitir una solicitud y luego decodificar miles de mensajes de respuesta, lo que resulta en un gran número de duplicarString s, s, etc. BigDecimal

Por lo tanto he creado una clase InternPool<T> que me permite internar cada clase de objeto. Internamente, el grupo usa un WeakHashMap<T, WeakReference<T>>. Por ejemplo:

InternPool<BigDecimal> pool = new InternPool<BigDecimal>(); 

... 

// Read BigDecimal from in buffer and then intern. 
BigDecimal quantity = pool.intern(readBigDecimal(in)); 

Mi pregunta: Estoy utilizando InternPool para BigDecimal pero debería también considerar el uso para Stringen lugar deString 's intern() método, que creo que utiliza el espacio PermGen? ¿Cuál es la ventaja de usar el espacio PermGen?

Answer 1

Es posible que el grupo String.intern() de la JVM sea más rápido. AFAIK, está implementado en código nativo, por lo que en teoría es debería ser más rápido y usar menos espacio que un grupo implementado usando WeakHashMap y WeakReference. Tendría que hacer una evaluación comparativa cuidadosa para confirmar esto.

Sin embargo, a menos que tenga un gran número de objetos duplicados de larga duración, dudo que el internamiento (ya sea en permGen o con sus propios grupos) haga mucha diferencia. Y si la proporción de objetos únicos a duplicados es demasiado baja, la interna solo aumentará la cantidad de objetos activos (lo que hará que el GC tarde más tiempo) y reducirá el rendimiento debido a los gastos generales del interinato, y así sucesivamente. Así que también recomendaría la evaluación comparativa de los enfoques "interno" versus "no interno".

Answer 2

Si ya tiene una clase InternPool, cree que es mejor usar eso que elegir un método de internamiento diferente para Cadenas. Especialmente desde String.intern() parece dar una garantía mucho más fuerte de lo que realmente necesita. Su objetivo es reducir el uso de memoria, de modo que la internación perfecta durante toda la vida útil de la JVM no es realmente necesaria.

también, que haría uso de la Google CollectionsMapMaker para crear un InternPool para evitar la re-creación de la rueda:

Map<BigDecimal,BigDecimal> bigDecimalPool = new MapMaker() 
    .weakKeys() 
    .weakValues() 
    .expiration(1, TimeUnits.MINUTES) 
    .makeComputingMap(
     new Function<BigDecimal, BigDecimal>() { 
     public BigDecimal apply(BigDecimal value) { 
      return value; 
     } 
     }); 

Esto le (implementado correctamente) claves y valores débiles, seguridad hilo daría, purga automática de entradas antiguas y una interfaz muy simple (un simple, bien conocido Map). Para estar seguro, también podría envolverlo usando Collections.immutableMap() para evitar que se estropee el código.