Todos sabemos que cada objeto asignado en Java añade un peso en futuros ciclos de recogida de basura y Optional<T>objetos no son diferentes. Utilizamos estos objetos con frecuencia para envolver anulable, lo que conduce a código más seguro, pero ¿a qué costo?
¿Alguien tiene información sobre qué tipo de presión adicional GC objetos opcionales añadir vs. nulos simplemente regresan y qué tipo de impacto que esto tiene sobre el rendimiento en sistemas de alto rendimiento?
Todos sabemos que cada objeto asignado en Java añade un peso en futuros ciclos de recogida de basura, ...
Eso suena como una declaración que nadie podía negar, pero vamos a ver el trabajo real de un recolector de basura, teniendo en cuenta las implementaciones comunes de JVM modernas y el impacto de un objeto asignado en él, sobre todo objetos como Optionalinstancias que son típicamente de naturaleza temporal.
La primera tarea del recolector de basura es identificar los objetos que aún están vivos. Los “colector de basura” pone el nombre de un enfoque en la identificación de basura, pero la basura se define como objetos inalcanzables y la única manera de averiguar qué objetos son inalcanzables, es a través del proceso de eliminación. Así que la primera tarea se resuelve por la que atraviesa y marcar todos los objetos alcanzables. Por lo que los costos de este proceso no dependen de la cantidad total de objetos asignados, pero sólo aquellos, que siguen siendo accesibles.
La segunda tarea es hacer que la memoria de la basura disponibles para nuevas asignaciones. En lugar de desconcertante con las lagunas de memoria entre los objetos todavía alcanzables, todos los recolectores de basura modernos funcionan mediante la evacuación de una región completa, la transferencia de todos los objetos vivos withing que la memoria a una nueva ubicación y la adaptación de las referencias a ellos. Después del proceso, la memoria está disponible para nuevas asignaciones como una manzana entera. Así que esto es de nuevo un proceso cuyos costes no dependen de la cantidad total de objetos asignados, pero sólo (una parte de) los objetos aún con vida.
Por lo tanto, un objeto como un temporal Optionalpuede imponer ningún coste en el proceso real de recolección de basura en absoluto, si se asigna y se abandonó entre dos ciclos de recogida de basura.
Con una pega, por supuesto. Cada asignación se reducirá la memoria disponible para las asignaciones subsiguientes hasta que no hay espacio a la izquierda y la recolección de basura tiene que tener lugar. Así que podríamos decir, cada asignación reduce el tiempo entre dos carreras de recolección de basura por el tamaño de la asignación de espacio dividido por el tamaño del objeto. Esto no sólo es una fracción bastante pequeño, sino que también se aplica solamente a un único escenario roscado.
En implementaciones como el Hotspot JVM, cada hilo utiliza un tampón de hilo local de la asignación (TLAB) para nuevos objetos. Una vez que su TLAB está llena, se buscará una nueva desde el espacio de asignación (también conocido como espacio de Edén). Si no hay ninguno disponible, se activará una recolección de basura. Ahora es bastante improbable que todos los hilos lleguen al final de su TLAB derecha al mismo tiempo. Así que para los otros hilos que todavía tienen algo de espacio en su TLAB dejó en este momento, no habría ninguna diferencia si hubieran asignado poco más todavía objetos ajustada en ese espacio restante.
La conclusión quizás sorprendente es que no todos los objetos asignados tiene un impacto en la recolección de basura, es decir, un objeto puramente local asignado por un hilo no desencadenar la próxima GC, podría ser totalmente libre.
Por supuesto, esto no se aplica a la asignación de una gran cantidad de objetos. La asignación de un montón de ellos hace que el hilo de asignar más TLABs y eventualmente desencadenar la recolección de basura antes de lo que no. Es por eso que tenemos clases como IntStreamlo que permite procesar un gran número de elementos sin asignar objetos, como sucedería con una Stream<Integer>, mientras que no hay ningún problema en el suministro de los resultados como una única OptionalIntinstancia. Como sabemos ahora, un solo objeto temporal tiene sólo un pequeño impacto en el GC, en su caso.
Esto ni siquiera tocó optimizador de la JVM, que puede eliminar las asignaciones de objetos en puntos calientes, en caso de escape Los análisis han demostrado que el objeto es puramente local.