Cómo escribir servlets seguros para subprocesos
a, variables de parámetros localizadas. El multiproceso no disfruta de las variables localizadas. Por lo tanto, debemos utilizar variables locales en los servlets siempre que sea posible. Por ejemplo, String user = "";user = request.getParameter("user");
b, use el bloque de código sincronizado Sincronizado para evitar llamadas asincrónicas al bloque de código. Esto significa que los subprocesos deben ponerse en cola para su procesamiento. Si bien utiliza el mismo bloque de código 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, ya que esto puede afectar gravemente al rendimiento.
2. Seguridad de subprocesos de atributos: atributos ServletContext, HttpSession y ServletRequest en el objeto: (subprocesos inseguros) ServletContext puede leer/escribir atributos de varios subprocesos al mismo tiempo y no es seguro para subprocesos. Para sincronizar la lectura/escritura de propiedades, aún necesita realizar una clonación profunda (). Por lo tanto, intente guardar los datos que se van a modificar (escribir) en el contexto del Servlet lo menos posible, y puede usar otros métodos para compartirlos entre múltiples Servlets. Por ejemplo, podemos usar el modo singleton para procesar datos compartidos. HttpSession: (Subproceso no seguro) El objeto HttpSession existe durante la sesión del usuario y solo se puede usar en subprocesos que procesan solicitudes que pertenecen a la misma sesión, y solo se puede acceder a él en subprocesos que procesan solicitudes que pertenecen a la misma sesión, por lo que acceder a la sesión Las propiedades del objeto son teóricamente seguras para subprocesos. Cuando un usuario abre varias ventanas del navegador que pertenecen al mismo proceso y el acceso a estas ventanas 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 múltiples propiedades de lectura y escritura. simultáneamente. En este punto necesitamos sincronizar los atributos de lectura y escritura: use el bloque sincronizado Sincronizado y use lectura/escritura para resolver este problema.
ServletRequest: (seguro para subprocesos) Para cada solicitud ejecutada por un subproceso de trabajo, se crea un nuevo objeto ServletRequest, por lo que solo se puede acceder al objeto ServletRequest en un único subproceso. Nota: Los objetos ServletRequest son válidos 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 función. Los servlets en sí son multiproceso y la creación de subprocesos en un servlet generará una ejecución compleja y problemas de subprocesos múltiples.
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 las solicitudes, en lugar de los problemas de eficiencia causados por poner en cola las solicitudes para una sola instancia. El servidor crea un grupo de múltiples instancias de clases de Servlet, asigna instancias de Servlet para responder a cada solicitud y luego las devuelve al grupo para esperar la siguiente solicitud. Esto puede causar problemas de acceso simultáneo. En este momento, las variables locales (campos) todavía son seguras, pero las variables globales y los datos compartidos no son seguros y deben sincronizarse. Para esta situación de múltiples instancias, la interfaz SingleThreadModel no puede resolver el problema de acceso concurrente.