Seguridad de subprocesos en el desarrollo de Java Swing

La API Swing está diseñada para ser potente, flexible y fácil de usar. Esperamos facilitar a los programadores la creación de nuevos componentes Swing, ya sea desde cero o ampliando algunos de los componentes que proporcionamos para ello. propósito No requerimos que los componentes Swing admitan el acceso de subprocesos múltiples. En lugar de eso, enviamos solicitudes al componente y ejecutamos la solicitud en un solo subproceso. Este artículo analiza los subprocesos y los componentes Swing. API de una manera segura para subprocesos, pero también para explicar por qué hemos elegido hacer esto. El esquema de subprocesos de este artículo incluye el siguiente contenido

Regla de subproceso único Solo se puede acceder al subproceso Swing mediante un subproceso en. Al mismo tiempo, en términos generales, este hilo es una excepción a la regla del hilo de envío de eventos. Se garantiza que algunas operaciones son envío de eventos seguro para subprocesos. Si necesita acceder a la interfaz de usuario desde algún lugar que no sea el manejo de eventos o el código de dibujo. Puede usar invokeLater de la clase SwingUtilities para solicitar que se ejecute cierto código en el hilo de envío de eventos. Este método regresará inmediatamente sin esperar a que se complete el código. invokeAndWait se comporta de manera similar a invokeLater excepto por esto El método esperará a que se ejecute el código. Generalmente, puede usar invokeLater en lugar de este método. Aquí hay algunos ejemplos del uso de estas API. Consulte también el ejemplo BINGO en "TheJavaTutorial", especialmente las siguientes clases: CardWindow ControlPane Player y OverallStatusPane. el método invokeLater, puede llamar al método invokeLater desde cualquier subproceso para solicitar que el subproceso de envío de eventos ejecute un código específico. Debe colocar el código que se ejecutará en el método de ejecución de un objeto Runnable y configurar este objeto Runnable como parámetro de invokeLater. . Método invokeLater Regresará inmediatamente sin esperar a que el hilo de envío de eventos ejecute el código especificado. Este es un ejemplo del uso del método invokeLater.

RunnabledoWorkRunnable=newRunnable　}

SwingUtilities. invokeLater; usando el método invokeAndWait. El método invokeAndWait y el método invokeLater son muy similares excepto que el método invokeAndWait esperará a que el hilo de envío de eventos ejecute el código especificado antes de regresar. invokeAndWait. Si realmente desea utilizar invokeAndWait, asegúrese de que el hilo que llama a invokeAndWait no retenga nada más durante la llamada. Bloqueos que los hilos puedan necesitar

Este es un ejemplo. de usar invokeAndWait

voidshowHelloThereDialogthrowsException　}; SwingUtilities invokeAndWait;}

Suposiciones similares Un hilo necesita acceder al estado de la GUI, como el contenido de un campo de texto. similar a esto

　voidprintTextField　throwsException　}; SwingUtilities invokeAndWait; System out println;}

Si puedes, es mejor evitar el uso de subprocesos, ya que puede resultar complicado depurar. programa más difícil En términos generales, los subprocesos no son necesarios para los subprocesos de trabajo estrictamente GUI, como la actualización de las propiedades de los componentes. Sin embargo, los subprocesos a veces son necesarios en las siguientes situaciones: Algunos casos típicos de uso de subprocesos para realizar una tarea que requiere mucho tiempo. enviar eventos a bloqueos de subprocesos. Los ejemplos incluyen situaciones en las que se realiza una gran cantidad de cálculos, lo que provoca que se carguen una gran cantidad de clases y para la creación de redes.

Realice repetidamente una operación cuando la E/S de red o disco esté bloqueada, generalmente con un período de tiempo predeterminado entre operaciones. Para esperar mensajes de los clientes, puede usar dos clases para ayudarlo a implementar subprocesos para crear un subproceso en segundo plano. operaciones que consumen Temporizador Crea un hilo para ejecutar o ejecutar algún código varias veces con un retraso definido por el usuario entre ejecuciones Utilice la clase SwingWorker La clase SwingWorker está implementada en SwingWorker java. Esta clase no está incluida en ninguna distribución de Java. para descargarlo por separado. La clase SwingWorker hace todo el trabajo sucio necesario para implementar un subproceso en segundo plano. Aunque muchos programas no necesitan un subproceso en segundo plano, un subproceso en segundo plano sigue siendo útil cuando se realizan operaciones que requieren mucho tiempo. y sensación del programa

SwingWorkers un ejemplo de uso de SwingWorker Para usar la clase SwingWorker primero debes implementar una subclase de la misma. En la subclase debes implementar el método de construcción y también incluir tus operaciones a largo plazo. de SwingWorker, SwingWorker crea un hilo, pero en lugar de iniciarlo, debe llamar al método de inicio de su objeto SwingWorker para iniciar el hilo. Luego, el método de inicio llamará a su método de construcción. Cuando necesite el objeto devuelto por el método de construcción, puedes llamar al método get de la clase SwingWorker. Este es un ejemplo del uso de la clase SwingWorker.

//En el método principal finalSwingWorkerworker=newSwingWorker　} //En el método de procesamiento de eventos de acción. JOptionPane showMessageDialog)

Cuando el método principal del programa llama al método de inicio, SwingWorker inicia un Se utiliza un nuevo hilo para crear una instancia de ExpensiveDialogComponent. El método principal también construye una GUI que consta de una ventana y un botón. Cuando el usuario hace clic en el botón, el programa se bloqueará si es necesario hasta que se cree ExpensiveDialogComponent. Luego, el programa muestra un cuadro de diálogo modal que contiene ExpensiveDialogComponent. Puede hacer esto en MyApplication java. Encuentre el programa completo y use la clase Timer. La clase usa un ActionListener para realizar o realizar una operación varias veces. Cuando crea un temporizador, puede especificar la frecuencia de ejecución de la operación y puede especificar el detector para el evento de acción del temporizador. Después de iniciar el temporizador, se inicia el detector de acciones. Se llamará al método actionPerformed definido por el detector de acciones del temporizador para realizar la operación. Esto significa que no es necesario utilizar el método invokeLater en él. Este es un ejemplo del uso de la clase Timer para implementar un bucle de animación

publicclassAnimatorApplicationTimer extendsJFrameimplementsActionListener publicvoidstartAnimationelse } publicvoidstopAnimation publicvoidactionPerformed }

La ejecución de todo el código de la interfaz de usuario en un hilo tiene varias ventajas. No es necesario tener un conocimiento profundo de la programación de subprocesos como ViewPoint y Trestle. Todos los componentes del kit de herramientas deben admitir completamente el acceso a subprocesos, lo que dificulta la expansión, especialmente para los desarrolladores que no dominan la programación de subprocesos. como SubArctic e IFC adoptan un diseño similar a Swing. Los eventos se organizan en un orden predecible. Envían los ejecutables en cola mediante invokeLater.

Los objetos se envían desde la misma cola que las solicitudes de extracción de eventos del temporizador del mouse y del teclado. En los kits de herramientas donde algunos componentes admiten completamente el acceso multiproceso, los cambios de componentes se intercalan con el manejo de eventos por los caprichos del programador de subprocesos. Los kits de herramientas aún menos costosos que intentan bloquear cuidadosamente secciones críticas dedican tiempo y espacio considerables a la gestión de bloqueos cada vez que un kit de herramientas llama a un método que podría implementarse en el código del cliente. Guarda su estado y libera todos los bloqueos para que el código del cliente pueda adquirir bloqueos si es necesario. Cuando se devuelve el control al kit de herramientas, el kit de herramientas debe recuperar sus bloqueos y restaurar el estado. Todas las aplicaciones tienen que asumir este costo, incluso las grandes. La mayoría de las aplicaciones no requieren acceso simultáneo a la GUI. El problema de admitir el acceso de subprocesos múltiples en el kit de herramientas Nuestro principio básico es que al diseñar y crear aplicaciones de subprocesos múltiples, especialmente aquellas que incluyen componentes GUI, se debe tener mucho cuidado al programar. En muchos casos, parecen simplificar enormemente la programación, lo que permite diseñar entidades autónomas simples centradas en una sola tarea. Sin embargo, en casi todos los casos dificultan mucho la depuración, las pruebas y el mantenimiento. o incluso imposible, independientemente de lo que la mayoría de los programadores estén capacitados para hacer, su experiencia y práctica, y las herramientas que utilizamos para ayudarnos a nosotros mismos no son capaces de utilizar. Lidiar con el no determinismo, como las pruebas exhaustivas, es casi imposible cuando los errores dependen del tiempo. Especialmente para Java, un programa debe ejecutarse en muchos tipos diferentes de plataformas de sistema operativo de máquina y cada programa debe ser preventivo y no preventivo. Funciona bien con la programación preventiva. Debido a estas dificultades inherentes, le recomendamos que lo piense dos veces. es absolutamente necesario usar subprocesos. Sin embargo, hay algunos casos en los que el uso de subprocesos es necesario, por lo que subArctic proporciona un mecanismo de acceso seguro para subprocesos lishixinzhi/Article/program /Java/gj/201311/27616