Problemas de seguridad de subprocesos de servlet
1. Cómo el contenedor de servlet maneja múltiples solicitudes al mismo tiempo
Primero, introduzca algunos conceptos:
Subproceso de trabajo: un grupo de subprocesos que ejecutan código
Programación Subproceso del despachador de subprocesos: cada subproceso tiene una prioridad de subproceso asignada y los subprocesos están programados para ejecutarse de acuerdo con la prioridad.
El servlet utiliza subprocesos múltiples para procesar solicitudes.
El servlet utiliza subprocesos múltiples para manejar múltiples solicitudes de acceso simultáneo. Un grupo de subprocesos es en realidad una colección de subprocesos de trabajo, y los servlets utilizan subprocesos de programación para administrar estos subprocesos de trabajo.
Cuando el contenedor recibe una solicitud de Servlet, el subproceso de programación seleccionará un subproceso de trabajo del grupo de subprocesos, pasará la solicitud al subproceso de trabajo y luego el subproceso ejecutará el método de servicio del Servlet. Durante la ejecución de este subproceso, el contenedor recibirá otra solicitud y el subproceso de programación seleccionará otro subproceso de trabajo del grupo de subprocesos para atender la nueva solicitud. Al contenedor no le importará si la solicitud es para el mismo servlet. Cuando el contenedor recibe varias solicitudes para el mismo Servlet al mismo tiempo, el método service() del Servlet se ejecutará simultáneamente en varios subprocesos.
El contenedor de Servlet utiliza un enfoque de instancia única y subprocesos múltiples para manejar las solicitudes de forma predeterminada, lo que reducirá la sobrecarga de generar instancias de Servlet y acortará el tiempo de respuesta a las solicitudes. Para Tomcat, puede establecer la cantidad de subprocesos en el grupo de subprocesos a través del elemento
En términos de implementación:
Responsabilidades que asume la clase Scheduler Thread Como su nombre indica, la responsabilidad de esta clase es programar hilos y sólo necesita utilizar sus propias propiedades para cumplir. sus responsabilidades. Por lo tanto, la clase asume la responsabilidad, que a su vez se concentra en el único objeto singleton.
Y otros objetos dependen de la responsabilidad de ese objeto específico, y necesitamos obtener ese objeto específico. Entonces esta clase es la implementación del patrón singleton.
2. Cómo desarrollar servlets seguros para subprocesos
1. Variables seguras para subprocesos: las variables aquí se refieren a campos y datos que disfrutamos (como los valores de los parámetros del formulario). ).
a.Variables de parámetros localizados. El multiproceso no disfruta de las variables localizadas. Por lo tanto, queremos utilizar variables localizadas en servlets siempre que sea posible.
Por ejemplo, String user = "";
user = request.getParameter("user");
Utilice el bloque sincronizado Sincronizado para evitar el código. bloquea para que no sea una llamada asincrónica. Esto significa que los subprocesos deben ponerse en cola para su procesamiento.
Cuando utilice el mismo bloque para minimizar el alcance del código de sincronización, no utilice la sincronización directamente en el método de servicio y el método de respuesta, de lo contrario afectará gravemente el rendimiento.
2. Atributos de seguridad de subprocesos: atributos en los objetos ServletContext, HttpSession y ServletRequest
ServletContext: (no seguro para subprocesos)
ServletContext puede ser leído por múltiples Hilos al mismo tiempo/Escribir atributos. No es seguro para subprocesos. Para sincronizar la lectura y escritura de propiedades o realizar un Clon profundo().
Por lo tanto, mantenga la menor cantidad posible de datos que se modificarán (escribirán) en el contexto del Servlet, y existen otras formas de abarcar múltiples Servlets, como usar el patrón singleton para * *** Disfrute de su datos.
HttpSession: (Thread-unsafe)
El objeto HttpSession existe durante la sesión del usuario y solo se puede acceder a él en las solicitudes de manejo de subprocesos que pertenecen a la misma sesión, por lo que las propiedades del objeto Session En teoría, el acceso es seguro para subprocesos.
Cuando un usuario abre varias ventanas del navegador que pertenecen al mismo proceso (donde el acceso pertenece a la misma sesión), se producirán múltiples solicitudes y se requerirán múltiples subprocesos de trabajo para manejar estas solicitudes, lo que puede resultar en Varios subprocesos leen y escriben propiedades simultáneamente.
En este punto, necesitamos sincronizar la lectura y escritura de propiedades: use el bloque Sincronizado Sincronizado y use lectores y escritores para resolver este problema.
ServletRequest: (seguro para subprocesos)
Para cada solicitud realizada por un subproceso de trabajo, se crea un nuevo objeto ServletRequest, por lo que solo se puede acceder al objeto ServletRequest en un subproceso. ServletRequest es seguro para subprocesos.
Nota: El objeto ServletRequest es válido dentro del alcance del método de servicio; no intente guardar una referencia al objeto de solicitud incluso después de que finalice el método de servicio.
3. Utilice clases de colección sincronizadas:
Utilice Vector en lugar de ArrayList y utilice Hashtable en lugar de HashMap.
4. No crees tu propio hilo en Servlet para completar una determinada función.
Los servlets son inherentemente multiproceso y la creación de subprocesos adicionales en un servlet generará una ejecución compleja y problemas de seguridad de múltiples subprocesos.
5. Al modificar objetos externos (como archivos) en múltiples Servlets, los bloqueos deben bloquearse para lograr un acceso mutuamente exclusivo.
6. La interfaz javax.servlet.SingleThreadModel es una interfaz de identificación. Si un Servlet implementa esta interfaz, el contenedor de Servlet garantizará que solo un subproceso pueda ejecutar el método de servicio en una instancia de servlet determinada. tiempo. . Pone en cola todas las demás solicitudes.
El servidor puede utilizar varias instancias para manejar solicitudes y evitar los problemas de eficiencia causados por poner en cola solicitudes para una sola instancia. El servidor crea un grupo de múltiples instancias de Servlet de la clase Servlet, asigna instancias de Servlet para responder a cada solicitud y luego las devuelve al grupo para esperar la siguiente solicitud. Esto crea el problema del acceso concurrente.
En este momento, las variables locales (campos) también son seguras, pero las variables globales y los datos que disfruta *** no son seguros y deben sincronizarse. Para esta situación de múltiples instancias, la interfaz SingleThreadModel no puede resolver el problema del acceso concurrente.
La interfaz SingleThreadModel ha quedado obsoleta en la especificación de Servlet.