Servlets are not thread safe. If you want to make it Servlet as Thread safe, you can implement SingleThreadInterface which is a blank Interface there is no methods (this is not recomend method, because it could slow the performance of your page) or you can synchronize methods by using synchronized keyword.
The SingleThreadModel interface is deprecated @ servlet2.4 and due for removal. The problem is that it causes a performance hit while only providing the illusion of thread safety.
As we know, when building a Website, we are primarily interested in the servlet’s two methods:
doGet(). The underlining method for both methods is
service(). Later, I look closer at these methods and how they relate to thread safety, but first let’s review the concept of a thread.
A thread is a single execution process; in other words, an individual, sequential flow of control within a program. When we say that a program is multithreaded, we are not implying that the program runs two separate instances simultaneously (as if you concurrently executed the program twice from the command line). Rather, we are saying that the same instance (executed only once) spawns multiple threads that process this single instance of code. This means that more than one sequential flow of control runs through the same memory block.
So what do we mean by thread-safe, you ask? When multiple threads execute a single instance of a program and therefore share memory, multiple threads could possibly be attempting to read and write to the same place in memory. Let’s look at an example. If we have a multithreaded program, we will have multiple threads processing the same instance (see Figure 1).
Figure 1. A multithreaded application
What happens when
Thread-A examines variable
instanceVar? Notice how
Thread-B has just incremented
instanceVar. The problem here is
Thread-A has written to the
instanceVar and is not expecting that value to change unless
Thread-Aexplicitly does so. Unfortunately
Thread-B is thinking the same thing regarding itself; the only problem is they share the same variable. This issue is not unique to servlets. It is a common programming problem only present when multithreading an application. You are probably thinking; “Well I didn’t ask for multithreading. I just want a servlet!” And a servlet is what you have. Let me introduce you to our friend the servlet container.
Your servlet container is no dummy
A lot of magic happens between the Web browser’s HTTP request and the code we write within the
doPost()methods. The servlet container makes this “magic” possible. Like any Java program, the servlet must run within a JVM, but for a Web application, we also have the complexity of handling HTTP requests—that’s where the servlet container comes in. The servlet container is responsible for your servlets’ creation, destruction, and execution; the sequence of these events is referred to as the servlet’s lifecycle.
The servlet’s lifecycle is an important topic, and thus, you will find it on Sun’s Java certification exam. The reason for its importance is primarily because so much of the servlet’s lifecycle is outside the programmer’s control. We do not worry a lot (for the most part) about how many of our servlet’s instances exist at runtime. Nor are we generally concerned about memory utilization regarding the creation and destruction of our servlets. The reason for our lack of concern is because the servlet container handles this for us (yes, more magic).