6

The following program :

public class SimpleCounter extends HttpServlet {

    int counter=0;

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/plain");
        PrintWriter writer = response.getWriter();
        counter++;
        writer.println("accessed " + counter + " times" );
    }
}

prints the incremented value of counter every time I access the url of this servlet. I read that the server creates an instance of this servlet and whenever there is a request for this servlet a new thread maps this request to the special instance created by the server.

When does the instance created by the server (to which thread maps the request) die? When do the threads created by a new request die?

Suhail Gupta
  • 19,563
  • 57
  • 170
  • 298
  • 1
    Is this in relation to a specific container? Some, like Google App Engine, aggressively reclaim apps that have not received requests for a period of time. – Mike Samuel Jan 30 '12 at 17:21
  • @ Mike Samuel not actually. But could be included in the answer/discussion – Suhail Gupta Jan 30 '12 at 17:25
  • Related: http://stackoverflow.com/questions/3106452/how-do-servlets-work-instantiation-session-variables-and-multithreading – BalusC Jan 30 '12 at 18:27

1 Answers1

4

The servlet instance is created when your webapp starts, or when it is first required (if lazy-init is set). It is disposed of when your webapp stops, when it is GCed. In a normal production environment, I'd dare to state this never really happens (not counting deploying a new version).

Most (if not all) servlet containers work with a thread pool. This means they reuse threads to handle requests. So these threads never die; they return to the pool when they finish executing the request.

Of course, they do die when you shut down the server :)

From the standpoint from your application, you really should try to make your servlet stateless, and you can safely consider that each request is executed in its own dedicated thread.

Joeri Hendrickx
  • 15,619
  • 4
  • 37
  • 53
  • _"you really should try to make your servlet stateless"_ can you explain this? – Suhail Gupta Jan 30 '12 at 16:44
  • Meaning you shouldn't keep any application state in there. That way you don't have to care when it is created or destroyed. Ideally,you shouldn't even care how many are instantiated (which is useful in a clustered environment). – Joeri Hendrickx Jan 30 '12 at 16:49
  • @SuhailGupta, in simple words, don't use any static variables in Servlets. – kosa Jan 30 '12 at 16:50
  • 1
    @ Joeri Hendrickx If the instance is destroyed when the app closes then there could be many instances alive and some of them may remain "idle" . If this happens does this create any kind of burden ? – Suhail Gupta Jan 30 '12 at 16:53
  • @SuhailGupta in a normal real-life environment, the app only stops when you stop the server. So then you don't really care. You would never just deploy/undeploy apps on a production server just for fun. During dev it could be an issue, but normally the GC will clean up the instances for you. The only way to have issues with this is to create memory leaks (put references to your servlet in the container) and then redeploy your application. – Joeri Hendrickx Jan 30 '12 at 19:37