La concurrencia no tiene que depender de subprocesos múltiples (como la concurrencia multiproceso de PHP), pero hablando de concurrencia en Java, la mayoría de ellos son inseparables de los subprocesos.
Implementación de hilos
Thread es la unidad básica de la programación de la CPU. La clase Thread es significativamente diferente de la mayoría de las API de Java. Todos sus métodos clave se declaran como nativos, lo que significa que este método no se usa o no se puede implementar utilizando medios independientes de la plataforma.
Hilo de la palanca del núcleo (KLT)
Los hilos directamente soportados por el núcleo del sistema operativo (Kermel, en lo sucesivo denominado el núcleo) son conmutados por el núcleo. El núcleo programa los hilos manipulando el planificador (Sheduler) y es responsable de asignar las tareas de los hilos a cada procesador.
Cada subproceso del núcleo puede considerarse como un avatar del núcleo, de modo que el sistema operativo tiene la capacidad de manejar varias cosas al mismo tiempo, y un núcleo que admite múltiples subprocesos se denomina núcleo de subprocesos múltiples (núcleo de subprocesos múltiples).
Los programas generalmente no usan KLT directamente, y una interfaz de alto nivel que usa KLT es Light Weight Process (LWP), que es el hilo del que generalmente hablamos. Dado que cada LWP es compatible con un KLT, Por lo tanto, solo admitiendo KLT primero puede haber LWP. Esta relación 1: 1 se llama 一对一的线程模型.
-
Limitaciones
Debido a que se basa en KLT, varias operaciones de subprocesos, como la creación, la desestructuración y la sincronización, requieren llamadas al sistema. El costo de las llamadas al sistema es relativamente alto, y debe alternar entre el modo de usuario y el modo kernel. En segundo lugar, cada LWP debe tener un soporte KLT, por lo que LWP consume ciertos recursos del núcleo (como el espacio de pila KLT), por lo que el número de LWP admitidos por un sistema es limitado.
Hilo de usuario
La creación, el cambio y la programación de varios detalles deben considerarse, la implementación y sus dificultades, y ha sido abandonada por lenguajes como Java y Ruby para mezclar hilos de usuario con procesos livianos.
Implementación de hilos Java
Los subprocesos de usuario todavía están completamente integrados en el espacio de usuario, por lo que las operaciones como la creación, el cambio y la destrucción de subprocesos de usuario siguen siendo económicos y pueden admitir subprocesos de usuario a gran escala. El puente entre ellos puede usar la función de programación de subprocesos y la asignación de procesador proporcionada por el núcleo, y la llamada al sistema del subproceso del usuario debe completarse con un subproceso liviano, lo que reduce en gran medida el riesgo de que todo el proceso esté completamente bloqueado.
En este modo mixto, la relación entre el número de subprocesos de usuario y los procesos livianos es indefinida, es decir, la relación entre N: M. Muchos sistemas operativos de la serie UN1X, como Solaris, HP-UX, etc. proporcionan subprocesos N: M Implementación del modelo.
Hilo de Java
Antes de JDK 1.2, se basaba en una implementación de subproceso de usuario llamada "Green-Threads". En JDK 1.2, se reemplazó con el modelo de subprocesamiento nativo del sistema operativo. Por lo tanto, en la versión actual de JDK, ¿qué admite el sistema operativo? El modelo de subprocesos determina en gran medida cómo se asignan los subprocesos de la máquina virtual Java. No hay forma de acordar las diferentes plataformas. La especificación de la máquina virtual no limita qué subprocesos Java de modelo de subproceso deben usar para lograr .
El modelo de subprocesos solo afecta el tamaño concurrente y los costos operativos de los subprocesos. Estas diferencias son transparentes para la codificación y ejecución de programas Java.
Para Siun JDK, sus versiones de Windows y Linux se implementan utilizando un modelo de subprocesos uno a uno, un subproceso Java se asigna a un proceso ligero, porque el modelo de subproceso proporcionado por los sistemas Windows y Linux es uno One-to-one y en la plataforma Solaris, debido a las características de subprocesamiento del sistema operativo pueden admitir uno a uno (a través de Bound
Threaids o Alternate Libthread) y muchos a muchos (a través de LWP / Thread Based Synchronization
Implementación) del modelo de subprocesos, por lo que la versión Solaris del JDK también proporciona dos parámetros de melocotón virtual específicos de la plataforma:
-XX: + UseLWPSynchronization (predeterminado) y -XX: + UseBoyndThreads para especificar explícitamente qué modelo de subprocesos utiliza la máquina virtual.
Programación de hilos Java
-
Programación de hilos
El proceso de asignación de derechos de uso del procesador a los subprocesos por parte del sistema, hay dos métodos principales de programación
-
Programación cooperativa de subprocesos
-
Programación preventiva de subprocesos
En un sistema de subprocesos múltiples que utiliza la programación cooperativa, el tiempo de ejecución del subproceso es controlado por el mismo subproceso. Después de que el subproceso ejecuta su trabajo, debe notificar activamente al sistema para cambiar a otro subproceso.
Multithreading cooperativo
-
Beneficio máximo
La implementación es simple, y debido a que el subproceso debe hacer lo suyo antes de cambiar el subproceso, la operación de conmutación es conocida por el subproceso, por lo que no hay problema de sincronización del subproceso
-
Las desventajas también son obvias.
El tiempo de ejecución del hilo es incontrolable
Usando un sistema de subprocesos múltiples con programación preventiva, el sistema asignará a cada subproceso el tiempo de ejecución, y el cambio de subprocesos no está determinado por el subproceso en sí. El camino es la programación preventiva. Aunque la programación de subprocesos de Java se realiza automáticamente por el sistema, aún podemos "sugerir" que el sistema asigne más tiempo de ejecución a ciertos subprocesos, lo que puede hacerse estableciendo la prioridad de subprocesos. El lenguaje Java ha establecido un total de 10 niveles de prioridad de subproceso (Thread.MIN_PRIORITY a Thread.MAX_PRIORITY). Cuando dos subprocesos están en el estado Listo al mismo tiempo, el subproceso con la prioridad más alta es más fácil de seleccionar para su ejecución por el sistema.
Los subprocesos de Java se implementan mediante la asignación a los subprocesos nativos del sistema, por lo que la programación de subprocesos depende en última instancia del sistema operativo. Aunque muchos sistemas operativos ahora proporcionan el concepto de prioridad de subprocesos, no necesariamente corresponde a la prioridad de los subprocesos de Java, como Hay 2147483648 (232) prioridades en Solaris, pero solo hay 7 en Windows, lo cual es mejor que un sistema con más prioridad de subproceso Java. Es mejor dejar un espacio en el medio, pero es menor que un sistema con menos prioridad de subproceso Java. Tiene que haber varias situaciones en las que la prioridad sea la misma, no solo que en algunas plataformas las diferentes prioridades realmente se convertirán en la misma, sino que también hay otras situaciones en las que no podemos confiar demasiado en la prioridad: la prioridad puede verse afectada por el sistema Cámbialo tú mismo.
Por ejemplo, hay un "Impulso de prioridad" (Impulso de prioridad) en el sistema de Windows, por supuesto, puede ser
Cerrado), su propósito general es que cuando el sistema encuentra que un hilo se está desempeñando particularmente "diligentemente", puede cruzar la prioridad del hilo para asignarle tiempo de ejecución. Por lo tanto, no podemos usar la prioridad en el programa para determinar exactamente qué grupo de subprocesos con el estado Listo se ejecutará primero.