Al utilizar hilos de Java, uno tiene que hacerse cargo de los problemas básicos que vienen con la concurrencia mediante la sincronización etc.hilos Tomcat Java vs roscas
yo sepa Tomcat también trabaja con hilos para manejar su carga de trabajo. ¿Por qué es así, que no tengo que pensar en hacer que mi código sea seguro para los hilos cuando se ejecuta en Tomcat?
Usted do tiene que hacer que su código sea seguro en tomcat. Tomcat invocará su código (es decir, sus servlets) desde varios subprocesos, y si ese código no es seguro para subprocesos, tendrá problemas.
Los hilos de Tomcat no son diferentes a los hilos que usted mismo crea.
Para añadir a lo skaffman ha mencionado, puede parecer que no es necesario pensar en múltiples hilos al escribir una aplicación web ya que el marco servlet/API está orientado completamente alrededor de los métodos de ejecución (service(), doGet(), doPost() , etc.) que se invocan una vez por solicitud HTTP.
Por lo tanto, en una aplicación simple, puede implementar estos métodos en su servlet y/o JSP o lo que sea y no pensar en lo que sucede cuando interactúan varios hilos.
Pero el segundo se inicia después de haber estado compartida entre los servlets o métodos de servicio, entonces posiblemente sin darse cuenta que son tratar con múltiples hilos de interactuar, y si no se tiene cuidado, es muy probable que tenga múltiples hilos o sincronización cuestiones. Tendrá que lidiar con esto porque en Tomcat (y supongo que todos los contenedores de servlets, aunque no sé si es requerido por las especificaciones del Servlet), cada solicitud es manejada por (posiblemente) un hilo diferente. Por lo tanto, si recibe dos solicitudes simultáneas, estas serán manejadas por dos hilos separados al mismo tiempo (al mismo tiempo).
Porque los contenedores Java EE están escritos de tal manera que manejan el enhebrado por usted. Usted escribe su código para que sea seguro para subprocesos y el contenedor hace el resto. Agrupa los hilos y los asigna uno por solicitud a medida que entran.
Si cree que Tomcat hace que su aplicación sea segura, escriba un servlet con variables de miembros mutables como un hashmap no simultáneo.
Luego haga que el servlet ponga las cosas en ese hashmap para cada solicitud. No tomará mucho tiempo obtener una hermosa excepción de simultaneidad.
Es por eso que, en general, para los componentes de tipo singleton, debe tener mucho cuidado con las variables miembro porque se comparten entre varios subprocesos que acceden al objeto.
Ahora el contenedor de servlets crea un nuevo objeto transitorio para cada solicitud (que es lo que hacen algunos marcos de aplicaciones web) podría poner comportamiento que interactuaba con las variables miembro en ese objeto transitorio y ser seguro para subprocesos.
Completando su respuesta: Por ejemplo, cuando escribe un servlet no debería tener variables locales en la clase de servlet. ¿Por qué? Porque la clase de servlet no está instanciada para cada hilo. Tomcat reutiliza instancias para varios hilos, por lo que todas sus variables deben estar dentro de los métodos doGet o doPost, por lo que se inicializan y asignan en diferentes lugares de memoria cada vez que se llama al método. – pakore
@pakore: las variables locales son los métodos internos. Te refieres a variables de instancia. –
Sí, quiero decir variables de instancia. Lo siento. Gracias por la corrección :). No puedo editar mi comentario ahora :( – pakore