用Java创建健壮的多线程可伸缩应用程序时应考虑哪些问题？

Question

I am planning to build a stand-alone / web based Java application. It should be capable of handling thousands of requests at a moment. Request messages come in through a TCP port say 6040. I have a dedicated thread to constantly listen for messages from clients. Once the message is read from the socket this thread will spawn a thread to service a request. So its basically one thread per request.

Servicing the request involves many database operations like calling stored procedures in remote databases, performing updates/insertions in local database and also logging. A response should be sent to the client after servicing the request.

I hope the scenario is clear. In short I want to build a robust multithreaded scalable application (to use the cliche). My questions are as follows:

1. Should the main thread listening to incoming requests spawn a thread for each request or should it just take one from a thread pool. What I'm asking is should I use Thread Spawning or Thread Pooling in my application.
2. Is it possible to deploy a standalone java application on clusters?
3. Is it a good idea to deploy and run it with the web-application (deployed on JBoss 7.1 server), which I intend to develop for administration purposes or should it be a standalone application?
4. In general what are the issues to be considered while building a Robust Multi-threaded Scalable applications in java

Answer 1

To ensure that your Java application should scale, there's basically one simple rule to follow: Don't share state.

All state should be local to the thread or in the backing datastore. This ensures that you can spin up unlimited copies of your application (on the same machine or not) that are entirely independent, and use a simple load balancer in front.

To answer your thread question specifically, it's almost always better to use an appropriately configured thread pool. You avoid the overhead of spawning the thread inline to your request and you can configure reasonable limits to avoid resource contention / exhaustion.

Answer 2

Consider using Threadpools rather than spawning a Thread when the request arrives to save some response time. Additionally, you could use non-blocking IO (check New I/O to have a single thread monitor many connections. Also, what Steven Schlansker said: don't share state!

Answer 3

I'm not sure if it really deserves to build it from scratch. From productivity perspective, it'll be much quicker to reuse existing web-container, like Jetty, Tomcat, etc. If you follow the Servlet API, you only need to describe your business logic, and container will deal with concurrency for you.

It takes a lot of time to tune performance of a web-container. Even large companies choose Tomcat/Jetty, such as Google's App Engine.