Is dangerous to start threads in Java and not to wait for them (with .join())?

When writing a multithread intern开发者_开发知识库et server in java, the main-thread starts new ones to serve incoming requests in parallel.

Is any problem if the main-thread does not wait ( with .join()) for them? (It is obviously absurd create a new thread and then, wait for it).

I know that, in a practical situation, you should (or "you must"?) implement a pool of threads to "re-use" them for new requests when they become idle.

But for small applications, should we use a pool of threads?

You don't need to wait for threads.

They can either complete running on their own (if they've been spawned to perform one particular task), or run indefinitely (e.g. in a server-type environment).

They should handle interrupts and respond to shutdown requests, however. See this article on how to do this correctly.

If you need a set of threads I would use a pool and executor methods since they'll look after thread resource management for you. If you're writing a multi-threaded network server then I would investigating using (say) a servlet container or a framework such as Mina.

The only problem in your approach is that it does not scale well beyond a certain request rate. If the requests are coming in faster than your server is able to handle them, the number of threads will rise continuously. As each thread adds some overhead and uses CPU time, the time for handling each request will get longer, so the problem will get worse (because the number of threads rises even faster). Eventually no request will be able to get handled anymore because all of the CPU time is wasted with overhead. Probably your application will crash.

The alternative is to use a ThreadPool with a fixed upper bound of threads (which depends on the power of the hardware). If there are more requests than the threads are able to handle, some requests will have to wait too long in the request queue, and will fail due to a timeout. But the application will still be able to handle the rest of the incoming requests.

Fortunately the Java API already provides a nice and flexible ThreadPool implementation, see ThreadPoolExecutor. Using this is probably even easier than implementing everything with your original approach, so no reason not to use it.

Thread.join() lets you wait for the Thread to end, which is mostly contrary to what you want when starting a new Thread. At all, you start the new thread to do stuff in parallel to the original Thread.

Only if you really need to wait for the spawned thread to finish, you should join() it.

You should wait for your threads if you need their results or need to do some cleanup which is only possible after all of them are dead, otherwise not.

For the Thread-Pool: I would use it whenever you have some non-fixed number of tasks to run, i.e. if the number depends on the input.

I would like to collect the main ideas of this interesting (for me) question.

1. I can't totally agree with "you don't need to wait for threads". Only in the sense that if you don't join a thread (and don't have a pointer to it) once the thread is done, its resources are freed (right? I'm not sure).

2. The use of a thread pool is only necessary to avoid the overhead of thread creation, because ...

3. You can limit the number of parallel running threads by accounting, with shared variables (and without a thread pool), how many of then were started but not yet finished.