1. Inicio
  2. Pregunta y respuesta
  3. ¿Deberían ejecutarse todos estos subprocesos predeterminados? Y mantienen mi JVM con vida?

¿Deberían ejecutarse todos estos subprocesos predeterminados? Y mantienen mi JVM con vida?

2012-02-09 6 views
8

Tengo una pregunta sobre los hilos que genera mi aplicación durante la ejecución y sobre su estado.¿Deberían ejecutarse todos estos subprocesos predeterminados? Y mantienen mi JVM con vida?

Tengo una aplicación Swing y noté un par de comportamientos extraños en algunos escenarios de prueba, usando Java VisualVM. Ejecutando mi programa durante más de 30 minutos sin hacer nada (solo comencé y lo dejé allí), noté lo siguiente.

Antes que nada, en la pestaña de Subprocesos veo muchos hilos vivos. Situation of my application after 30mins or so of not doing anything

lectura (entre otras cosas) Default threads like, DestroyJavaVM, Reference Handler, Signal Dispatcher y What are these threads which are spwaned when a Java application begins its execution? entiendo la mayoría de estos hilos tienen una muy buena razón para estar allí. (Todavía estoy tratando de averiguar los "RMI TCP")
Tengo dudas, sin embargo, sobre su estado. ¿Es normal que los primeros seis de ellos hayan estado en funcionamiento el 100% del tiempo?

Además, ¿podría alguno de estos subprocesos explicar un consumo de montón como el siguiente? Heap consumption of my application doing nothing, over 30+ mins

me di cuenta de que una gran cantidad de casos de HashMap $ Entrada y TreeMap $ de entrada están referenciados y creado por las bibliotecas procedentes de sun.rmi. * Y pensé que podría estar relacionado con los temas "RMI TCP" ..

Por último, pero no por eso menos importante, si intento deshacerme de() mi JFrame principal, el cuadro desaparecerá, pero la aplicación seguirá ejecutándose ... ¿podrían ser esos hilos la razón (o parte de ella)? ??

Gracias a todos.

Fuente

2012-02-09 mdm

Respuesta

8

Todavía estoy tratando de averiguar los "RMI" TCP

Estos hilos se utilizan para aceptar y manejar las conexiones JMX a través de RMI. Está utilizando uno ahora mismo cuando mira JVisualVM. ¿Has notado tu IP en el nombre del hilo del trabajador?

Tengo dudas, sin embargo, sobre su estado. ¿Es normal que los primeros seis de ellos hayan estado en funcionamiento el 100% del tiempo?

El hecho de que el hilo es ejecutable no quiere decir que sea funcionamiento y el consumo de tiempo de CPU. Citando Thread.State:

  • NUEVO - Un hilo que aún no ha comenzado está en este estado.

  • RUNNABLE - Un subproceso que se ejecuta en la máquina virtual Java se encuentra en este estado.

  • BLOCKED - Un hilo bloqueado esperando un bloqueo del monitor se encuentra en este estado.

  • ESPERANDO - Un subproceso que está esperando indefinidamente que otro subproceso realice una acción en particular se encuentra en este estado.

  • TIMED_WAITING - Un subproceso que está esperando que otro subproceso realice una acción durante un tiempo de espera especificado se encuentra en este estado.

  • TERMINADO - Un hilo que ha salido está en este estado.

Como se puede ver esta lista no menciona acerca a la espera de E/S como zócalos. Los hilos que realizan esta tarea todavía están marcados como ejecutable. Claramente esperar datos no consume ninguna CPU. También las conexiones de aceptación de hilos son ejecutables, mientras que no hace nada. Se despertará cuando el cliente intente establecer una nueva conexión.

Además, ¿podría alguno de estos subprocesos explicar un consumo de montón como el siguiente?

Su consumo de montón es normal y saludable. La forma del diente de sierra es causada por la recolección de basura que elimina objetos que ya no son necesarios. JVM también se da cuenta de que el consumo de su pila es bastante constante, por lo que sigue reduciendo el tamaño máximo de almacenamiento dinámico, ya que cree que no necesita tanto (gráfico naranja).

Por último, pero no menos importante, si trato de dispose() mi JFrame principal, el propio marco se Desaparecer, pero la aplicación seguirá funcionando .... esos hilos podrían ser la razón (o parte de ella) ??

Eso es porque solo está cerrando un JFrame, pero no toda la aplicación. El Swing EDT (event dispatching thread) aún se está ejecutando. Pero esto no tiene nada que ver con eso. Simplemente use:

jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

en su marco principal.

TL; DR

Su aplicación es completamente bien, si las roscas y el consumo de memoria se tiene en cuenta. ¡No te preocupes!

Ver también

Fuente

2012-02-09 10:05:03

+2

+1 por la respuesta bien organizado! Acerca de JFrame, sé que podría usar EXIT_ON_CLOSE pero la aplicación podría ser llamada por un framework más grande y, si solo uso EXIT_ON_CLOSE, mataría a toda la instancia de JVM. dispose() en el último cuadro desplegable debe matar la aplicación de todos modos, ¿verdad? – mdm

+0

@mdm: no soy un experto de Swing, pero estoy citando ['Window.dispose()'] (http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#dispose()): * Nota: Cuando se elimina la última ventana visualizable dentro de la máquina virtual Java (VM), la VM puede finalizar.* –

+1

El consejo en esta respuesta es excelente, pero no voy a mentir: voté +1 puramente porque usaste TL; DR ;-) –

Cuestiones relacionadas

 Cuestiones relacionadas