Java Singleton vs estático: ¿existe un beneficio real en el rendimiento?

Question

Estoy fusionando una rama CVS y uno de los cambios más importantes es el reemplazo dondequiera que ocurra de un patrón Singleton con clases abstractas que tienen un bloque de inicialización estático y todos los métodos estáticos.

¿Es esto algo que vale la pena conservar, ya que requerirá fusionar muchos conflictos? ¿Qué tipo de situación estaría analizando para que valga la pena esta refactorización?

Estamos ejecutando esta aplicación en Weblogic 8.1 (es decir, JDK 1.4.2)

---

Lo siento Thomas, déjame aclarar...

la versión HEAD tiene el patrón singleton tradicional (constructor privado, getInstance(), etc.)

la versión de la rama no tiene constructor, es una "clase abstracta pública" y modificó todos los métodos del objeto para que sean "estáticos".El código que solía existir en el constructor privado se mueve a un bloque estático.

Luego, se cambian todos los usos de la clase, lo que provoca múltiples conflictos en la combinación.

Hay algunos casos en los que se realizó este cambio.

Answer 1

Desde un punto de vista estricto del rendimiento en tiempo de ejecución, la diferencia es realmente insignificante.La principal diferencia entre los dos radica en el hecho de que el ciclo de vida "estático" está vinculado al cargador de clases, mientras que para el singleton es un ciclo de vida de instancia normal.Por lo general, es mejor mantenerse alejado del negocio ClassLoader, así evitará algunos problemas complicados, especialmente cuando intenta recargar la aplicación web.

Answer 2

Usaría un singleton si fuera necesario para almacenar cualquier estado y clases estáticas en caso contrario.No tiene sentido crear una instancia de algo, ni siquiera una sola instancia, a menos que necesite almacenar algo.

Answer 3

La estática es mala para la extensibilidad ya que las subclases no pueden ampliar ni anular los métodos y campos estáticos.

También es malo para las pruebas unitarias.Dentro de una prueba unitaria no se puede evitar que los efectos secundarios de diferentes pruebas se extiendan, ya que no se puede controlar el cargador de clases.Los campos estáticos inicializados en una prueba unitaria serán visibles en otra o, peor aún, ejecutar pruebas simultáneamente arrojará resultados impredecibles.

Singleton es generalmente un patrón aceptable cuando se usa con moderación.Prefiero usar un marco DI y dejar que administre mis instancias por mí (posiblemente dentro de diferentes ámbitos, como en Guice).

Answer 4

Si mi publicación original tenía la comprensión correcta y la discusión de Sun a la que estaba vinculado es precisa (lo cual creo que podría serlo), entonces creo que hay que hacer un equilibrio entre claridad y rendimiento.

Hágase estas preguntas:

1. ¿El objeto Singleton aclara lo que estoy haciendo?
2. ¿Necesito un objeto para realizar esta tarea o es más adecuado para métodos estáticos?
3. ¿Necesito el rendimiento que puedo obtener al no utilizar un Singleton?

Answer 5

Desde mi experiencia, lo único que importa es cuál es más fácil de burlar en las pruebas unitarias.Siempre sentí que es más fácil y natural burlarse de Singleton.Si su organización le permite usar JMockit, no importa ya que puede superar estas preocupaciones.

Answer 6

¿Ayuda esta discusión?(No sé si es tabú vincular a otro foro de programación, pero prefiero no citar toda la discusión =))

Debate solar sobre este tema.

El veredicto parece ser que no hace una diferencia suficiente en la mayoría de los casos, aunque técnicamente los métodos estáticos son más eficientes.

Answer 7

Escriba algún código para medir el rendimiento.La respuesta dependerá de la JVM (el JDK de Sun puede funcionar de manera diferente a JRockit) y de las marcas de VM que utilice su aplicación.