Hago una herramienta y proporciono una API para el mundo externo, pero no estoy seguro de si es segura para subprocesos. Porque los usuarios pueden desear usarlo en un entorno de múltiples hilos. ¿Hay alguna forma o herramienta que pueda usar para verificar si mi API es segura para subprocesos en Java?¿Hay alguna forma o herramienta que pueda usar para verificar si mi API es segura para subprocesos en Java?
Pruebas de tensión o herramientas de análisis estático como PMD y FindBugs puede destapar algunas errores de concurrencia en el código. De modo que estos pueden mostrar si su código es no seguro para subprocesos. Sin embargo, nunca pueden probar si es seguro para subprocesos.
El método más eficaz es una revisión exhaustiva del código por desarrollador (es) con experiencia en concurrencia.
El uso de jMeter, aunque no es a prueba de balas, sí ayuda a identificar las estupideces de la implementación. Me encontré con problemas de subprocesamiento porque alguna clase en el fondo tenía un objeto estático SimpleDateFormat que se estaba utilizando para generar parámetros de fecha para las consultas SQL.El controlador subyacente, en un punto, comenzó a quejarse sobre los parámetros de fecha inválidos, lo que me ayudó a identificar este problema en particular. – Fil
Siempre puede probarlo con herramientas como jmeter.
Pero el principal problema con los hilos es que son en su mayoría impredecibles, por lo que incluso con las pruebas de tensión, etc. no puede estar 100% seguro de que será totalmente seguro para hilos.
Recursos:
JMeter (y casi cualquier otra herramienta) puede ayudarlo a descubrir problemas, pero nunca puede verificar que su código sea correcto (especialmente con código multiproceso). –
@Joachim Sauer, exactamente lo que estoy diciendo. No mostrará problemas de seguridad de subprocesos, pero puede descubrir algunos. –
Pruebas como esas son como pruebas unitarias ... no pueden decirle dónde está correcto su código, solo le pueden decir dónde está roto. Eso no los hace menos útiles :) – RHSeeger
Sin. No hay tal herramienta. Es muy difícil probar que un programa complejo es seguro para subprocesos.
Debes analizar tu programa detenidamente para asegurarte de que es seguro para la ejecución de subprocesos. Considere la posibilidad de comprar "simultaneidad Java en la práctica" (muy buena explicación de concurrencia en java).
No puede y nunca podrá probar automáticamente que un programa ya no es enhebrado, que puede probar que un programa es correcto (a menos que piense que ha resuelto el programa de detención, que no lo hizo).
Así que, no, no puede verificar que una API sea segura para la rosca.
Sin embargo, en algunos casos puede demostrar que está roto, ¡lo cual es genial!
Puede que también esté interesado en la detección automática de interbloqueos, que en muchos casos simplemente "simplemente funciona". Estoy enviando un programa Java en cientos de computadoras de escritorio con un detector de punto muerto instalado y es una herramienta maravillosa. Por ejemplo:
http://www.javaspecialists.eu/archive/Issue130.html
También puede resaltar probar la aplicación de diversas maneras.
Los programas de múltiples hilos falsos tienden a no funcionar muy bien cuando hay una carga alta en el sistema.
Aquí hay una pregunta que hice acerca de cómo crear fácilmente crear una alta carga de CPU en un Un * x sistema, por ejemplo:
La demostración de que un único programa finito y no arbitrario carece de ciertos defectos no es un ejemplo de un problema equivalente de detención. De lo contrario, no existiría el compilador de verificación de tipos. – soru
Ésta es una variante (o los llamados "reducción") del problema de detención. Por lo tanto, es probablemente imposible de resolver. para todos los casos no triviales. (Sí, eso es una edición)
Eso significa que puede encontrar errores por cualquier medio habitual (estadísticas, lógica) pero nunca puede probar por completo que no los hay.
Esto es obviamente incorrecto: un único programa de subprocesos siempre es seguro para la ejecución de subprocesos, y un verificador que simplemente verifica el enhebrado de las llamadas de API detectará el programa de un solo subproceso el 100% del tiempo. – soru
@soru: tienes razón. No se puede * resolver en general *, mientras que * casos específicos * (como programas triviales con una sola operación) se puede probar que es correcto. Desafortunadamente, los triviales son fáciles de probar, por lo general no son lo suficientemente interesantes ;-) –
En mi experiencia, es bastante claro dividir los programas en dos clases: – soru
Supongo que las personas que dicen que probar que un programa arbitrario multiproceso es seguro para la ejecución de subprocesos es imposible, de alguna manera, es correcto. Un programa multiproceso arbitrario, codificado sin seguir pautas estrictas, simplemente tendrá errores de conexión, y no se puede probar válidamente algo que no sea cierto.
El truco no es escribir un programa arbitrario, sino uno con la lógica de enhebrado lo suficientemente simple para posiblemente ser correcto. Esto entonces puede ser validado inequívocamente por una herramienta.
La mejor herramienta de este tipo que conozco es CheckThread. Funciona sobre la base de anotaciones o de archivos de configuración xml. Si marca un método como '@ThreadSafe' y no lo es, entonces obtiene un error en tiempo de compilación. Esto se comprueba al mirar el código de bytes para las operaciones inseguras de subprocesos, p. secuencias de lectura/escritura en campos de datos no sincronizados.
También maneja aquellas API que requieren métodos para llamar en hilos específicos, p. Oscilación.
En realidad, no maneja interbloqueos, pero estos pueden eliminarse estáticamente sin siquiera requerir anotación, mediante el uso de una herramienta como Jlint. Solo necesita seguir unos estándares mínimos, como asegurarse de que los bloqueos se adquieran de acuerdo con un DAG, no por gusto.
cómo lo prueba con jmeter y vea qué sucede o cualquier otra herramienta de prueba automatizada, tal vez amoladora – ant
Puede sincronizar todo. No se escalaría a varios hilos, pero tampoco se rompería debido al mal enhebrado. ¿Su objetivo de eficiencia es solo la falta de falla catastrófica? –
Pregunta relacionada que podría ayudar http://stackoverflow.com/questions/424516/any-satisfactory-approaches-to-unit-testing-thread-safety-in-java – JRL