¿Tiene la excepción de JAVA un impacto en el rendimiento?

Cuando se brinda soporte técnico a los clientes de OneAPM, a menudo vemos muchas excepciones que los clientes no conocen. Después de eliminar estas anomalías, el código se ejecuta a una velocidad mucho más rápida que antes. Esto nos da la conjetura de que el uso de excepciones en el código puede tener una sobrecarga de rendimiento significativa. Debido a que las excepciones son una parte importante del manejo de errores, no es posible descartarlos, por lo que necesitamos medir el impacto del manejo de excepciones en el rendimiento. Podemos observar el impacto del manejo de excepciones en el rendimiento a través de un experimento.

Experimento

Mi experimento se basa en un código simple que lanza una excepción al azar. Desde un punto de vista científico, esta no es una medida completamente precisa, y no sé qué hará el compilador HotSpot con el código en ejecución. Pero de todos modos, este código debería darnos alguna información básica.

Los resultados son muy interesantes: el costo de lanzar y atrapar excepciones parece ser extremadamente bajo. En mi caso, es alrededor de 0.02 milisegundos por excepción. A menos que realmente lances demasiadas excepciones (nos referimos a 100,000 veces o más), esto es básicamente insignificante. Aunque estos resultados muestran que el manejo de excepciones en sí no afecta el rendimiento del código, no resuelve el siguiente problema: ¿Quién es responsable del enorme impacto de la excepción en el rendimiento?

Obviamente me perdí algunos problemas importantes.

Repensando un poco, me di cuenta de que me había perdido una parte importante del manejo de excepciones. No pensé en lo que hiciste cuando ocurrió la excepción. En la mayoría de los casos, es más probable que atrape una excepción. Y el problema está aquí: en general, intentará complementar el problema y dejar que la aplicación siga funcionando en el usuario final. Entonces, lo que me perdí es: " " El código complementario que se ejecutó para manejar la excepción " ". La pérdida de rendimiento puede llegar a ser bastante significativa dependiendo del código suplementario. En algunos casos, esto puede significar volver a intentar conectarse al servidor, y en otros casos puede significar el uso del esquema de reversión predeterminado, y la solución provista por este esquema definitivamente traerá un rendimiento muy bajo. Esto parece dar una buena explicación para el comportamiento que vemos en muchos casos.

Pero no creo que esté bien analizarlo aquí, pero creo que aquí falta algo más.

Stack trace

Todavía siento curiosidad por este problema, al monitorear el rendimiento de la situación al recopilar rastros de strack.

La situación que ocurre a menudo debería ser así: escriba la excepción y su trayectoria de pila y trate de averiguar dónde está el problema.

He modificado el código para esto y, además, recopilé una traza de excepción. Esto hace que la situación cambie dramáticamente. La recopilación de trazas de stracks anómalas tiene un impacto en el rendimiento que es 10 veces mayor que simplemente capturar y lanzar excepciones. Por lo tanto, si bien el seguimiento de huelga ayuda a entender dónde algo salió mal (y posiblemente ayuda a entender por qué ocurrió el problema), hay una penalización en el rendimiento. Ya que no estamos hablando de un rastro de strack, el impacto aquí es a menudo muy grande. En la mayoría de los casos, lanzamos y atrapamos excepciones en múltiples niveles. Veamos un ejemplo simple: el cliente del servicio web se conecta al servidor. Primero, hay una excepción de falla de conexión en el nivel de la biblioteca de Java. Después de eso, habrá una excepción de fallo de cliente en el nivel de marco, y luego puede haber una excepción de fallo de llamada de lógica empresarial en el nivel de aplicación. Hasta el momento, se han recogido un total de tres rastros de strack. En la mayoría de los casos, puede ver estos rastreos de strack desde los archivos de registro o el resultado de la aplicación, y la escritura de estos rastreos de strack largos también tendrá un impacto en el rendimiento.

Conclusión

En primer lugar, no es una buena idea abandonar la anomalía debido al impacto en el rendimiento. Las excepciones ayudan a proporcionar una manera consistente de resolver problemas de tiempo de ejecución y ayudan a escribir código limpio. Pero debemos rastrear el número de excepciones lanzadas en el código, lo que puede causar un impacto significativo en el rendimiento. Por lo tanto, OneAPM hará un seguimiento de las excepciones lanzadas por defecto — — en muchos casos, las personas se sorprenderán de las excepciones que ocurren en el código y la penalización de rendimiento al resolver esas excepciones. En segundo lugar, aunque es útil utilizar excepciones, debe evitar capturar demasiados rastros de strack. Las excepciones deben estar diseñadas para situaciones anómalas y deben tenerse en cuenta al usarlas. Por supuesto, en caso de que no quiera seguir buenos hábitos de programación, el lenguaje Java le permitirá saber que hacerlo acelerará su programa y lo alentará a hacerlo.