Overview of the Java Executor Framework (Part 1)

This video gives the first part of an overview of the Java Executor framework, focusing on its support for thread pool.

[ruixue]

Prof Doug, I noticed from practice that the ThreadPoolExecutor's execute() will not terminate without calling shutdown() or shutdownNow(). Some practical books told this also but without reasoning. So I tried to find out the reason from this video, but did not yet.

However, I tested with other subclasses of Executor such as ForkJoinPool, the execute() of ForkJoinPool indeed terminate without shutdown() or shutdownNow()

So it would be better to know the design reason of ThreadPoolExecutor :)

[ruixue]

0:10 Java executor framework has a lot of pieces
0:14 UML
0:33 3 different types of thread pools
0:50 Executor framework
0:57 main benifits of executor framework: it decouples the creation and management of threads from the application logic and the tasks it performs
1:27 Executors utility class
2:04 why we need thread pool
2:07 concurrent programs typically have to handle large numbers of of clients
2:25 usu a bab idea (even you have a lot of cores) to spawn a thread per client
2:32 so if you have a thousand clients, you don't want a thousand threads typically, 2:39
2:52 thousands of threads will not happen simoultaneously
2:58 dynamically spawning a thousand threads per client can occur an excessive amount of processing overhead 3:03 because you have to go ahead and create all these threads (takes time and consume memory)
3:24 a more effective way of scaling up system's performance is to use thread pool
3:35 amortize the memory and processing overhead associated with spawning threads, 3:41 we don't spawn a thread per client but a fixed/variable-sized (with a size limit) number of threads
3:52 you can decide the size of thread pool by factors: number of cores, how IO intensive your tasks are vs computer intensive etc.
4:05 main differences between IO intensice tasks and computer intensive tasks with respect to the number of threads in your pool
4:32 IO is not CPU bound, compute intensive is CPU bound
4:56 with IO intensive tasks, the thread is blocked waiting for IO, 5:15 when the thread is blocked, another thread can run
5:19 with computer/CPU intensive operation, tasks are just running without stop => they don't benifit from lots of threads
5:49 Java executor service framework provides several ways to organize thread pool
5:54 fix-sized thread pool -
6:04 simple example
6:22 this might not to suitable for a web server
6:52 cached thread pool - threads are created on-demand in response to client workload
7:27 if the threads are not used for a certain amount of time, they will be shut down automatically
7:36 fork/join pool - work stealing with deque
8:25 idea is to keep the system running with high utilization

[SanjeevKumar-hjfb]

Prof Doug, When we call fork() on any ForkJoinTask, I guess the resulting subtask which is another ForkJoinTask must be added to the Dequeue of some worker thread.
My question is does it get added to the same worker thread's dequeue that called fork or it is some other thread's dequeue?

My guess is : the forked subtask probably gets added to some other worker thread's dequeue, not to the dequeue owned by the thread calling fork. But, that would result in contention, right?