¿Deben los desarrolladores de Java saber acerca de los algoritmos de recolección de basura? [cerrado]


11

Recientemente me preguntaron en una entrevista si conozco algún algoritmo de recolección de basura.

Sabía qué es la recolección de basura, pero nunca pensé en aprender sobre los algoritmos de recolección de basura, ya que como desarrollador nunca tuve que preocuparme por eso y el recolector de basura hace todo el trabajo por mí.

¿Ustedes piensan que los desarrolladores de Java deberían saber sobre los algoritmos de recolección de basura? En caso afirmativo, ¿puede decirme cuáles debo investigar?



1
Sí, deberían. De lo contrario, corren el riesgo de escribir software que se rompe bajo una gran carga.
quant_dev

Respuestas:


9

Creo que conocer los algoritmos de recolección de basura no es importante en absoluto si desarrolla "software estándar" y no plataformas de software. Debe tener una comprensión básica de cómo funciona un recolector de basura y eso es todo. A menos que experimente retrasos críticos en su software causados ​​por la recolección de basura o necesite optimizar el uso de la memoria.

Si está interesado en esos algoritmos, consulte esta publicación mía: ¿Cuáles son los algoritmos detrás de GC de pausa baja?


7

La recolección de basura es un problema informático interesante y no trivial.

Conocer y comprender un algoritmo para él es una indicación de que tiene un interés y una comprensión bastante profundos de estos algoritmos. Incluso si no ha estudiado el algoritmo GC de Java, me impresionaría si alguien pudiera dar una descripción razonable de qué estructuras de datos y algoritmos se utilizarían.

En términos de programador de Java, sería bueno si un desarrollador pudiera describir las ventajas y desventajas de GC, lo que incluiría un poco de conocimiento sobre cómo se implementa. Esto indicaría tener interés en cómo funcionan las herramientas que usa en lugar de usarlas pasivamente. Conocer los costos también lo ayudaría a programar de una manera que minimice los costos.

No diría que esto es "conocimiento requerido" para ganarse la vida como desarrollador de Java, sino una habilidad adicional que demuestra que eres capaz y estás dispuesto a profundizar un poco más de lo que necesitas saber para hacer el trabajo de hoy.


2
Conocer una comprensión de los conceptos básicos con los que estaría de acuerdo (comprender las cosas te hace un mejor programador). El problema es que si conoce los detalles intrincados y luego use that informationdiseña su código. Esto puede causar problemas a medida que se mejora el GC y sus suposiciones acerca de cómo el GC ya no se mantiene y el código deja de ser óptimo (y en el peor de los casos puede obstaculizar el GC). Es bueno saberlo, pero debe diseñar su código utilizando las mejores prácticas, no teniendo en cuenta una implementación específica; los compiladores y GC siempre están mejorando y las optimizaciones de macro eventualmente dejarán de ser útiles.
Martin York

Estaba pensando más en la línea de que si sabes algo sobre cómo Stringse implementa, entonces no concatenarás en una cadena usando +un bucle.
JohnMcG

4

Veo dos razones por las que uno debería saber cómo funciona el recolector de basura (o cualquier algoritmo / tecnología). Aquí están:
1. Obtiene un mejor conocimiento de lo que está sucediendo debajo del código que escribe. Esto a menudo puede ayudarlo a escribir código más eficiente, lo que garantizará un mejor rendimiento. En algunos casos esto puede ser vital. (Tuve una experiencia desagradable cuando GWT confiaba en el recolector de basura del navegador, y tuvimos una gran pérdida de memoria con Chrome. Así que tuvimos que ver qué causó exactamente la pérdida).
2. Tales algoritmos son siempre (o casi siempre, no, siempre) de confianza para desarrolladores inteligentes, calificados, calificados y con experiencia. Por lo tanto, estudiar su enfoque puede ser muy útil.

Veo otra razón por la que le hicieron esa pregunta en la entrevista. Algunos desarrolladores (mi ex colega en particular) piensan que un desarrollador no es lo suficientemente inteligente o trabajador, si él / ella no sabe tales cosas. No estoy de acuerdo con esta afirmación. Pero de todos modos, conocer esas cosas es una buena manera de impresionar a su entrevistador.


1
Estoy de acuerdo con (2) y la mitad de (1) (ayuda en la depuración). Pero existen peligros en (1) y diseñe su código para que funcione con una implementación particular de un GC en el sentido de que ya no será óptimo cuando se mejore el GC o pase a una implementación con un tipo diferente de GC.
Martin York

@Loki Astari, tienes razón acerca de que es peligroso para implementaciones específicas. Pero, por otro lado, hay cosas que no cambian (al menos durante mucho tiempo), por ejemplo, los principios de recolección de basura de .NET.
superM

@superM: En realidad, el GC de Mono es significativamente diferente del de Microsoft, y está en proceso de ser reemplazado por otro completamente diferente.
Jörg W Mittag

@superM: No me parece una evolución tan lenta de Java: en.wikipedia.org/wiki/Java_version_history (parece que una vez al año hay un nuevo parche o actualización). Con un nuevo lanzamiento el próximo año. Ahora, eso no significa que GC se actualice cada vez, pero muestra el potencial para ello.
Martin York

@Loki Astari, eso es correcto. Mucho en el desarrollo de software sigue cambiando rápidamente, y nuestro trabajo es seguirle el ritmo. Además, todos los cambios se basan en lo que ya existe, por lo que no esperaría ningún cambio radical en 1 o 2 versiones.
SuperM

4

Debe conocer la recolección de basura generacional y los detalles sobre la recolección de basura de Java (los espacios PermGen, Eden y Tenured). También debe estar familiarizado con la recolección de basura en general (como por qué el conteo de referencias suele ser una mala idea y por qué es mejor marcar y barrer). También recomendaría leer sobre algunas implementaciones alternativas (como el GC "sin pausa" en Zing JVM de Azul y el proyecto de metrónomo en tiempo real de IBM ).


3

Debe tener ALGUNOS conocimientos sobre cómo funciona la recolección de basura para Java por dos razones:

Primero, si no sabe cómo funciona, entonces accidentalmente puede tomar decisiones de diseño que conducen al peor rendimiento en su aplicación real. Esto se vuelve cada vez menos probable a medida que el GC mejora, pero si tiene una opción de algoritmos en su aplicación, entonces saber algo sobre el GC significa que puede elegir uno con conocimiento de lo que va a hacer, en lugar de descubrir que causa mal comportamiento.

En segundo lugar, si no sabe cómo funciona, no puede ajustar el GC para una aplicación determinada. La mayoría de los programadores de Java nunca necesitan ajustar el GC, ya que los parámetros predeterminados funcionan lo suficientemente bien la mayor parte del tiempo. Si hace algo que sale de eso 'la mayor parte del tiempo', entonces puede encontrarse ajustando los parámetros del GC. Hacerlo sin conocimiento del GC es simplemente girar las perillas al azar: es posible que obtenga algo útil, pero es más probable que arruine las cosas aún más.

Entonces, aunque no esperaría que un buen programador de Java supiera todo sobre GC, espero que ese programador sepa en algún nivel cómo funciona el GC en la JVM y cuáles son las compensaciones para eso Algoritmo GC.


1

Sí, todos los desarrolladores de Java definitivamente deberían saber qué está sucediendo detrás de escena de la máquina virtual y eso incluye el trabajo de recolección de basura.

Sin embargo, el nivel de conocimiento es otra cuestión. No esperaría que un desarrollador normal explicara la diferencia de una implementación real (tendría que investigarlo yo mismo), sin embargo, el principio básico de lo que hace un GC y cuáles deberían ser los pros y los contras para administrar la memoria usted mismo claro.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.