Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am fairly new to Java and my experience is limited to Web Based Applications running on a Web Container (Jboss in my case).

Am I correct in saying that for Web Applications the web container takes care of multi-threading? If so, can I introduce new treads in a Web Based applications? Is there any advantage in doing so and in what scenario one would need to do that?

share|improve this question
Till EE6 Thou Shall Not Use Threads; EE7 introduces Concurrency Utilities. – Martin Schröder Jun 12 '13 at 18:20
up vote 16 down vote accepted

Am I correct in saying that for Web Applications the web container takes care of multi-threading?

Most webservers (Java and otherwise, including JBoss) follow a "one thread per request" model, i.e. each HTTP request is fully processed by exactly one thread. This thread will often spend most of the time waiting for things like DB requests. The web container will create new threads as necessary.

Some servers (in the Java ecosystem primarily Netty) do asynchronous request handling, either with a "one thread does everything" model, or something more complex. The basic idea there is that having lots of waiting threads wastes resources, so working asynchronously can be more efficient.

If so, can I introduce new treads in a Web Based applications?

It's possible, but should be done very carefully, since errors (like memory leaks or missing synchronization) can cause bugs that are very hard to reproduce, or bring down the whole server.

Is there any advantage in doing so and in what scenario one would need to do that?

Well, the advantage is that you can do stuff in parallel. Using threads to improve pure computational speed is something you should not do on a webserver, as it would slow down the handling of other requests. That kind of thing should be done on a separate server, probably using some sort of job queue.

A legitimate scenario for multithreading in the context of handling an HTTP request might be if you need to access other network resources, e.g. call several different web services. If you do it in a single thrad, you have to wait for each call to finish in turn. But if you use multiple threads, the total waiting time is only the delay of the single slowest call.

share|improve this answer
Makes sense. Is ExecutorService Interface the best way to go about creating new threads in a web application? – kapricanon Jun 12 '13 at 13:30
@kapricanon: yes, unless you have some specific requirements it can't handle, or your web server already has something similar. – Michael Borgwardt Jun 12 '13 at 13:53

In response to your question:

How is multi-threading different in a Java based Web Application vs Stand-alone Java Application

It is not different. Usually the software web applications are built upon will provide some multi-threading already by making each new request a thread. By you can use/create threads just as you would any other application.

Indeed multi-threading can give you drastic performance increases if you use it right. For I/O intensive tasks such as network access and disk drive access the performance increase is nearly always guaranteed. For computationally intensive tasks you should stick to the rule of one thread per core in the server. For example if your core has an i7 processor you should stick to 7 threads to do computational tasks.

In response to your question:

Is there any advantage in doing so and in what scenario one would need to do that?

Michael Borgwart says you should not do this to improve computational speed. I disagree, as this article suggests multi-threading can help provide responsiveness when users need a computationally heavy task done. In plain English, users wont have to wait as long to complete computationally heavy tasks with multi-threading.

If you intend to use threads a lot, I suggest use of a thread pool. This will reduce the overhead of creating threads.

share|improve this answer
how does this answer the question asked? – gnat Oct 14 '13 at 16:18
Answers should stand on their own merits. If you want to comment you'll have to earn 50 reputation points first. – ChrisF Oct 15 '13 at 8:07

Well this is a nice question and I think most of the developers who work in web application development don't use multithreading explicitly. The reason is quite obvious since you are using a application server to deploy your application, the application server internally manages a thread pool for incoming requests.

Then why use multithreading explicitly? What is need a web application developer expose himself to multithreading?

When you work on a large scale application where you have to server many request concurrently it is difficult to serve every kind of request synchronously because particular kind of request could have been doing a lot processing which could bring down the performance your application.

Lets take an example where a web application after serving particular kind of request has to notify users through email and SMS. Doing it synchronously with the request thread could bring down the performance of your web application. So here comes the role of mutlithreading. In such cases it is advisable to develop a stand alone multithreaded application over the network which is responsible for sending email and SMS only.

share|improve this answer
why this answer is downvoted? – Anurag Sharma Sep 14 '15 at 5:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.