Análisis en profundidad del modelo de subprocesos Tomcat NIO
La implementación NIO de Tomcat se encuentra principalmente en el componente conector, que es uno de los dos componentes principales de Tomcat. Su tarea principal es recibir la solicitud de conexión TCP enviada por el navegador y crear una solicitud y un objeto de respuesta para intercambiar datos con el solicitante respectivamente. Luego se generará un hilo para manejar la solicitud, y los objetos de solicitud y respuesta generados se pasarán al hilo que maneja la solicitud. El hilo que maneja la solicitud es lo que hace el componente contenedor.
Todo el componente del conector consta de tres partes: Http11NioProtocol, Mapper y CoyoteAdapter. Http11NioProtocol incluye controladores de conexión NioEndpoint y HTTP 11. NioEndpoint es el módulo principal de Http11NioProtocol responsable de recibir y procesar sockets. El controlador de conexión http 11 es el controlador de conexión. NioEndpoint implementa principalmente el aceptador de subprocesos de monitoreo de solicitudes de socket, el subproceso Nipol de socket y el grupo de subprocesos de procesamiento de solicitudes.
El flujo de procesamiento interno de NioEndpoint es el siguiente:
El receptor recibe el hilo del socket. Aunque es un conector basado en NIO, todavía recibe el socket en el método tradicional serverSocket.accept(), obtiene el objeto SocketChannel y luego lo encapsula en una organización de clase de implementación de Tomcat. Apache. Objeto Tomcat.util.net.NIOChannel. Luego, el objeto NioChannel se encapsula en el objeto PollerEvent y el objeto PollerEvent se envía a la cola de eventos. Este es un modelo típico de productor-consumidor. Los receptores se comunican con los hilos de votación a través de colas. El receptor es el productor de la cola de eventos y el encuestador es el consumidor de la cola de eventos.
El objeto selector se mantiene en el hilo del sondeador y NIO completa la lógica basada en el selector. No solo hay un selector en el conector, sino también un selector que controla el tiempo de espera al leer y escribir datos en el socket. Esto se presentará más adelante en BlockSelector. Primero puede marcar este selector mantenido en el hilo de la encuesta como el selector principal. El encuestador es el hilo principal implementado por NIO. Primero, como consumidor de la cola de eventos, tomamos el objeto PollerEvent de la cola y luego usamos el evento OP_READ para registrar el canal en el objeto en el selector principal. Luego, el selector principal realiza una operación de selección, itera a través de los sockets que pueden leer datos, obtiene los subprocesos de trabajo disponibles del grupo de subprocesos de trabajo y pasa el socket al subproceso de trabajo. Todo el proceso es una implementación típica de NIO.
Worker Después de que el subproceso Worker obtiene el socket enviado por Poller, encapsula el socket en el objeto SocketProcessor. Luego saque el objeto Http11NioProcessor del Http11NioProcessor y llame a la lógica CoyoteAdapter desde el procesador HTTP 11 NIO, al igual que la implementación BIO. En el hilo de trabajo, leerá la solicitud http del socket, la analizará en un objeto HttpservletRequest, la enviará al servlet correspondiente y completará la lógica, y luego enviará la respuesta al cliente a través del socket.
En el proceso de lectura y escritura de datos en el socket, a diferencia del típico NIO sin bloqueo, el evento OP_READ u OP_WRITE no se registra en el selector principal, pero las lecturas y escrituras se completan directamente a través del socket. Bloqueado, pero en el control de tiempo de espera, se utiliza el mecanismo selector NIO. Pero este selector no es el selector principal mantenido por el hilo Poller, sino un selector mantenido por el hilo BlockPoller, que se denomina selector auxiliar.
El objeto nioendpoint mantiene un objeto nioselepool, y este nioselepool mantiene un hilo BlockPoller. Esta es la lógica de NIO basada en el selector auxiliar. Por ejemplo, cuando se ejecuta un servlet, obtiene una respuesta y escribe datos en un socket. El proceso de escritura final llama al método de escritura de NioBlockingSelector.
Después de ser procesada por el modelo de subproceso NIO dentro de NioEndpoint, la solicitud de Socket monitoreada por el receptor se convertirá en un SocketProcessor que se ejecuta en el ejecutor y se entregará al controlador de conexión HTTP 11 para su procesamiento durante el proceso en ejecución El controlador de conexión HTTP 11 se descargará desde el HashMap concurrente.
Al mismo tiempo, podemos ver que el hilo del receptor encapsulará el socketChannel recibido (una solicitud de socket) en un LinkedQueue concurrente. p>
Uno o más subprocesos aceptadores, cada uno con su propio selector. El aceptador solo es responsable de aceptar nuevas conexiones. Una vez establecida la conexión, se registrará en otros hilos de trabajo.
Múltiples subprocesos de trabajo, a veces llamados subprocesos IO, son específicamente responsables de la lectura y escritura de IO. Una forma de lograr esto es que, al igual que Netty, cada hilo de trabajo tiene su propio selector, que puede ser responsable de los eventos de lectura y escritura de IO de múltiples conexiones. Cada conexión pertenece a un hilo. Otro enfoque es utilizar un hilo especial para monitorear eventos de IO; estos hilos tienen sus propios selectores. Una vez que se monitorean los eventos de lectura y escritura de IO, las operaciones de IO no se empaquetarán en un grupo de subprocesos ejecutables para su ejecución como el primer método. En este caso, cada conexión puede ser operada por múltiples subprocesos al mismo tiempo, lo que mejora la concurrencia en comparación con el primer método, pero también puede causar problemas de subprocesos múltiples, por lo que debemos tener más cuidado al manejarlo. El modelo NIO de Tomcat es el segundo.
Entonces, los parámetros generales son el número de subprocesos receptores y el número de subprocesos trabajadores.
Consulte el documento oficial https://tomcat.apache.org/tomcat-8.5-doc/config/http.html? SPM = 5176.100239 blogcont 39093.5. >Estos Los parámetros incluyen principalmente lo siguiente:
1) Recuento de aceptación
Antes de ser aceptada por el canal de socket del servidor, la conexión se almacena temporalmente en la cola. AcceptCount es la longitud máxima. de la cola. La aceptación de ServerSocketChannel es una solicitud para eliminar continuamente conexiones de esta cola. Por lo tanto, cuando la aceptación de ServerSocketChannel no se elimina a tiempo, puede provocar un retraso en la cola. Una vez que la conexión esté llena, será rechazada;
2) AcceptorThreadCount
. El hilo aceptador solo es responsable de que la conexión de las solicitudes que han establecido conexiones se saque de la cola anterior. Cuando se inicia, ServerSocketChannel se utiliza para escuchar el puerto de conexión (como 8080). Varios subprocesos de destinatarios pueden llamar al método de aceptación de ServerSocketChannel para obtener nuevas conexiones. El parámetro AcceptorThreadCount es el número real de subprocesos aceptadores utilizados;
A partir de la arquitectura general de Tomcat, este artículo presenta las clases relacionadas con NIO en Tomcat y el flujo de procesamiento de una solicitud de red en Tomcat. Finalmente, se presenta el papel y el impacto de varios parámetros clave en Tomcat en el modo de subproceso NIO. Creo que será útil para los estudiantes que quieran comprender el modo de subproceso NIO de Tomcat.