56

My multithreading concepts are weak and trying to learn.

In Java what I know is, we can't call a thread more than once: 

Thread t = new Thread; //Some Runnable
t.start();

t.start(); //Illegal and throw Exception at runtime.

As far as I know, it throws exception when you call t.start() again because the associated stack for the thread is destroyed once it goes out of run() method and you are trying to initialize things again.

In that case, what I know about thread pool is, it gives better performance & saves time because there is no need to create new thread (I read in this).

If there is no need to create new thread in thread pool scenario, then how it works with same thread which just finished its run method, will that thread can be used again?

I read this, and it says that "Most of the executor implementations in java.util.concurrent use thread pools, which consist of worker threads. This kind of thread exists separately from the Runnable and Callable tasks it executes and is often used to execute multiple tasks."

So what is Worker thread here, is it something different then normal Java threads?

With this link, I got something but still confused on what kind of stuff can be eliminated when we use thread pool and why it gives better performance than using normal java threads.

So can we say like this,

Thread has three parts,

  1. Creation (Telling OS that it is new thread, create stack for it.)
  2. Execute Runnable with run() method.
  3. Destroying threads.

So, considering above 3 steps, With thread pool step 1 and step 3 can be eliminated after fixed number of thread creation. Only step 2 for each task will be executed that is why threadpool is faster? Can we say like this? Am I correct?

Lore
  • 1,286
  • 1
  • 22
  • 57
Jayesh
  • 6,047
  • 13
  • 49
  • 81
  • 2
    Here's a [simple, open-source Java thread pool](http://www.informit.com/articles/article.aspx?p=30483&seqNum=6). You can actually inspect the code to see how it works, *under the hood*. – Nate Nov 04 '13 at 10:41
  • the link you pointed creates n WorkerThread object inside ThreadPool Constructor and calls start() method on it, which is nothing but creating n Thread objects and calling start method on it then how Threadpool helps increasing performance. – Jayesh Nov 04 '13 at 11:13
  • 2
    [this link](http://arashmd.blogspot.com/2013/06/java-threading.html#trpool) may help –  Nov 04 '13 at 11:37
  • @user2511414: link is useful but still in link you can see that 10 Threads is already created then how Threadpool helps in performance? I mean what part is eliminated in Threadpool, then creating new Thread explicitly which improve performance? – Jayesh Nov 04 '13 at 11:55
  • 3
    @Jayesh Idle threads don't bother system, the bad thing is creating and destorying threads to much, in fact thread pool utilize a thread many times instead of destroy and create it again. [this link](http://arashmd.blogspot.com/2013/06/java-threading.html#mgrmem) also may describe the issue. –  Nov 04 '13 at 11:59
  • @user2511414: So the part of code which says OS that this is new Thread and create stack for it and other background part related to creation of Thread could be eliminated for each Thread correct? I want to know what exact things it has to do that it take much time? – Jayesh Nov 04 '13 at 12:10
  • 2
    @Jayesh each thread needs it's own stack, also OS should switch(switch-context) and manage the threads. beside threads are so effective for some kinda jobs, they would be enemy as well, having to much thread is not very well(at least for CPU). with trhead pool you accomplished two(general) things. 1.use(recycle) a thread many times 2.manage the memory by limiting creation of to much threads. the time you mentioned is for switching-context and thread private memory that takes time for each creation and destroy. –  Nov 04 '13 at 12:18

4 Answers4

41

If there is no need to create new Thread in ThreadPool scenario, then how it works with same thread which just finished its run method, will that Thread can be used again?

Simple - the original thread never actually completes. It just waits for another task to execute. In pseudo-code:

// No, this isn't even slightly accurate! General impression only :)
while (!pool.isShutdown()) {
    Runnable task = pool.waitForTaskOnQueue();
    task.run();
}

(Obviously when a thread pool is shut down, it would need to stop waiting threads from waiting for another task, too - but hopefully you get the general idea.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • It's close enough. Sadly, all too many thread tutorials seem to go on endlessly about creating threads, letting them run and waiting for them to terminate with join(). If you're lucky, it might mention, somewhere on page 17, that you can put a while loop in them and wait for signals at the top. I would not be unhappy if Thread.join() was deprecated :) – Martin James Nov 04 '13 at 10:43
  • but to have the effect of Multithreading, several Threads needs to be created? when you call executor.execute(runnable1), executor.execute(runnable2)..... but "task.run();" doesn't need to start in new Thread then only it will work as multithreaded? – Jayesh Nov 04 '13 at 10:44
  • @Jayesh: If you need parallel execution, you'd need a thread pool to have multiple threads. But each thread may still execute several tasks in its lifetime. It's important to separate the "supports handling multiple tasks" from "supports N-way parallelism". Each thread will only run a single task at a time, yes. – Jon Skeet Nov 04 '13 at 10:47
  • @JonSkeet: Can you please explain your words "supports handling multiple tasks" from "supports N-way parallelism". I am getting it but not clear still. can you edit your answer and explain this point in bit detail. or can you point some links where this things are explained. Thanks. – Jayesh Nov 04 '13 at 10:52
  • @Jayesh: Suppose you have a thread pool with 5 threads in. You can submit 1000 tasks to that thread pool, and they will all get executed - but it will only execute 5 at a time. They won't be *batched* into lumps of 5 - each thread will just pick up another task when it's completed the previous one. For short-lived tasks, that's generally much more efficient than creating 1000 threads... where after all, you're unlikely to have 1000 CPU cores in the first place, and thread creation/scheduling is an overhead. – Jon Skeet Nov 04 '13 at 10:57
  • my point here is to be run in parallel for 5 Threads, 5 times Thread t1,t2,t3,t4,t5 need to be done then only they can run in parallel right or it is not like that? other then this 5 when 6th one will come for that then one more time Thread t6 need to be created that is what I am getting. – Jayesh Nov 04 '13 at 11:04
  • @Jayesh: That depends on the thread pool implementation. Some will use a fixed set of threads, some will allow other threads to be created (and potentially die off) within certain limits. – Jon Skeet Nov 04 '13 at 11:07
6

The process workes in two parts:

Submission of task: Thread pools are tightly coupled with a blocking Queue. When we say executor.execute(runnable). The runnable/callable is enqued in the queue.

Execution of tasks: Now the tasks need to be picked up from the queue. Lets say whenever a task is submitted in the queue, it must be picked up and executed.

So there are threads which will be running infinite loop and watching the queue for tasks. As soon as the tasks are available one thread will pick it and execute.

Sonu
  • 712
  • 9
  • 7
2

In Thread Pool Instead of creating new threads when new tasks arrive, a thread pool keeps a number of idle threads that are ready for executing tasks as needed. After a thread completes execution of a task, it does not die. Instead it remains idle in the pool waiting to be chosen for executing new tasks.

You can limit a definite number of concurrent threads in the pool, which is useful to prevent overload. If all threads are busily executing tasks, new tasks are placed in a queue, waiting for a thread becomes available

Vinayak Bansal
  • 21
  • 5
1

So, considering above 3 steps, With Threadpool step 1 and Step 3 can be eliminated after fixed number of Thread Creation. only Step 2 for each task will be executed that is why Threadpool is faster? can we say like this? am I correct?

Yes you are correct. Thread creation and destruction is one of the costly task. As in a thread pool threads are already created so the overhead of thread creation is not there. But if you have much more higher threads than it should have, it will be pretty bad for your application. It may go OutofMemorry or may be into some other issues. So to fix a thread pool size use the below formula:

no of threads = 2 * no_of_cores * no_of_disks * percentage CPU utilization you need * (1 + (W/ C))

(W/C) is the fraction stating Wait time to Compute time.

Trying
  • 14,004
  • 9
  • 70
  • 110
  • http://stackoverflow.com/questions/4759570/finding-number-of-cores-in-java To Find the Number of Cores in Java :) – Decoded Feb 22 '16 at 18:15