0:05 in this video I will give you a quick
0:07 overview of Java multi-threading and
0:10 concurrency but before I do so I will
0:11 just give you a quick overview of the
0:14 history of multitasking and
0:17 multi-threading in general just a quick
0:18 heads up this video is an introduction
0:20 to Java concurrency and multi-threading
0:22 on a conceptual level therefore it does
0:25 not contain any code examples however
0:27 this video is part of a playlist of
0:29 videos about Java concurrency and later
0:31 videos in this playlist do contain code
0:33 examples if you check out the
0:34 description below the video you will
0:36 find a link to this playlist as well as
0:38 to my textual Java concurrency tutorials
0:42 which also contain code examples in the
0:45 early days of computing a computer could
0:49 only run one program or process as
0:52 programs also sometimes referred to at a
0:55 time only one at a time right so that in
0:57 that case if you were working inside of
0:59 word or something similar like that and
1:01 you needed to make some changes to
1:03 something inside Excel you would have to
1:06 close down word and jump into Excel and
1:08 change the thing you needed to change
1:10 and then close Excel again and an open
1:15 word up again and then that kind of
1:18 workflow quickly becomes quite annoying
1:22 for the user to solve this problem
1:24 multitasking was invented and
1:27 multitasking basically means that now
1:30 the computers can run more than one
1:33 application at the same time and but
1:36 since the CPU can only execute one
1:38 program at a time the CPU or the
1:41 computer solves this problem by
1:43 executing one application for a little
1:46 bit of time then switching to another
1:49 application and executing that for a
1:50 little bit of time then switching to
1:52 another application and executing that
1:55 for a little bit of time then switching
1:58 back to the first one and repeating this
2:02 way it will appear to the user as if all
2:04 of these application our applications
2:06 are actually running at the same time
2:09 even though they are actually only
2:10 running one at a time but the switches
2:13 are so fast that the user cannot see or
2:15 feel the difference it feels as if
2:17 the applications are running at the same
2:22 time I said that it was the CPU that is
2:24 switching between these applications
2:26 here these tasks but in reality it is a
2:29 combination of the CPU and their
2:31 operating system right so the CPU
2:33 executes the operating system and the
2:36 operating system then switches between
2:40 the tasks here and modern-day CPUs have
2:42 some built-in features that makes this
2:45 task switching easier for the operating
2:50 system multi-threading is the same
2:53 principle as multitasking except
2:56 multi-threading happens within an
2:58 application so instead of having one
3:01 thread of execution inside of an
3:02 application you can actually have
3:06 multiple threads of execution inside of
3:08 an application so for instance an
3:11 application might both be downloading a
3:14 file in one thread and playing music in
3:19 another and the way that threats are
3:22 executed is similar to how tasks our
3:25 applications are executed first one
3:28 thread here gets to execute a little bit
3:32 on the CPU and then the operating system
3:34 or the application depending on who
3:38 controls this thread switches to another
3:40 thread and now this thread gets to
3:43 execute a little bit and now we switch
3:45 completely the operating system switches
3:47 completely to another application and
3:51 then that first thread here inside of
3:52 this application gets to execute a
3:55 little bit on the CPU and then it
3:57 switches to another thread and then this
3:59 thread gets to execute a little bit on
4:01 the CPU and then we switch completely
4:03 out of this application and back to the
4:05 first one here or to any other
4:09 application running on the computer
4:11 modern computers typically come with
4:16 multiple CPUs in or CPUs with multiple
4:18 cores in which in practice is the same
4:22 thing so on a modern computer you might
4:25 actually have multiple CPUs executing
4:27 these applications
4:31 and in that case that means that some of
4:33 the applications might actually be
4:36 running at the exact same time because
4:38 they're being executed by different CPUs
4:41 for instance here this application here
4:42 might be running at the exact same time
4:44 as this application down here because
4:48 they are executed by different CPUs now
4:51 each CPU may still context switch
4:53 between applications and internally
4:56 between threads within each application
5:00 so some of these applications and
5:02 threats are not exactly executing at the
5:04 same time but some of them will be
5:08 because of the multiple CPUs right by
5:12 the way in this diagram it looks as if
5:15 each application is only executed by a
5:18 single CPU but that is not necessarily
5:21 the case it is possible to have an
5:24 application running which has one thread
5:28 executed by one CPU and another thread
5:31 executed by another CPU down here for
5:34 instance and in that case each of the
5:36 threads might actually be executing at
5:38 the exact same time because they are
5:41 running on different CPUs and this is
5:45 often the case in software that requires
5:47 a lot of compute power for instance 3d
5:50 rendering software video editing
5:52 software when the final video has to be
5:58 exported or computer games now that we
5:59 have discussed what multi-threading is
6:02 let's dive deeper into why
6:05 multi-threading is a good idea first of
6:07 all we can achieve better CPU
6:10 utilization with multi-threading take a
6:12 look at this example here I have an
6:15 application which has one thread running
6:17 here and at some point here the thread
6:20 needs to load some data from disk offer
6:23 network now while this data is loading
6:26 from the disk the CPU cannot really do
6:29 anything within this threat of execution
6:31 up here it needs the data before it can
6:35 continue but instead of simply being
6:38 idle and wasting these CPU cycles the
6:40 computer can switch to another threat and
6:41 and
6:44 execute whatever work this threat needs
6:45 to get done
6:49 and at some point when the CPU or they'd
6:51 like the operating system feels that it
6:53 is time to switch back or like when the
6:56 full data here is loaded it can switch
6:57 back from this threat down here to the
6:59 first threat which can now continue
7:02 running because now that data has been
7:06 loaded into memory in this way we can
7:10 better utilize the CPU while IO tasks
7:14 are running another benefit we can
7:17 achieve what multi-threading is better
7:21 io utilization look at this example here
7:24 first we have a thread running within an
7:27 application and now this threat needs to
7:30 load some data from the disk and then
7:33 it's been some time processing these
7:35 dates and after that it loads the next
7:39 data and then it processes that data etc
7:42 now as you can see we are actually
7:45 switching between full utilization of
7:48 the CPU and full utilization of the
7:50 network i/o but we have these gaps in
7:53 between here and here and here and here
7:56 where we are not using either and
7:59 imagine then that we have another thread
8:00 it's not the same thread but another
8:03 thread running which you can see here
8:05 this thread up here is idle right in the
8:08 CPU is idle up here while it's loading
8:11 data from the network so we can have
8:13 another thread here which has asked for
8:16 some data which it can now process and
8:20 then it this one can now load data while
8:22 this thread up here is not loading any
8:24 data from the disk or network right it's
8:29 actually utilizing this empty space here
8:32 this idle I opened with is being
8:35 utilized by another thread and so and
8:38 thus it can switch between these two
8:42 threads that are utilizing the i/o at
8:44 different times so when one is waiting
8:47 for IO the other one is using the CPU
8:50 and when the other one is using the CPU
8:51 the other one can use
8:55 I owe and you know the discarded network
8:59 and actually you might even have two
9:03 threads using the for instance the
9:04 network cut at the same time for
9:06 instance if they are both downloading a
9:08 file or waiting for a file to download
9:11 from a server which is slow you might
9:13 actually be able to to start multiple
9:17 i/o downloads at the same time from
9:20 different threads and so in this way we
9:22 can not only better utilize the CPU but
9:25 also the i/o capabilities of the
9:27 computer that bandwidth to the disk and
9:31 to the network a third benefit we can
9:33 get from multi-threading is higher
9:36 application responsiveness as perceived
9:37 by the user
9:40 imagine you have a GUI application a
9:43 graphical user interface the user clicks
9:46 on a button here it starts some some
9:49 some processing here and then it starts
9:51 a long-running task which runs in the
9:52 background and when the task is finished
9:55 the thread can go back to updating the
9:58 user interface and responding to further
10:03 input from the user now in this period
10:06 here the threat is busy executing the
10:08 long-running task and thus it cannot
10:11 respond to the users input or update the
10:14 user interface and that means that in
10:17 this time period here the application
10:22 will appear unresponsive to the user now
10:27 to avoid that we can start the
10:29 long-running task in a separate thread
10:33 down here right and thus the CPU will
10:35 switch forth and back between the
10:37 long-running task in the separate thread
10:41 and the main UI thread in the UI thread
10:44 and so it switches forth and back and to
10:46 the user it appears as if the
10:48 application is still responsive because
10:52 at all these times here the application
10:55 still responds to the users input but
10:58 sooner or later because this application
11:00 will probably not use all of the CPU
11:03 time sooner or later enough CPU time
11:04 will have been a look
11:08 to the long-running task in the separate
11:10 threat down here and so it finishes and
11:14 then the user interface can be updated
11:16 saying oh by the way this file is now
11:18 fully downloaded or whatever else this
11:22 long-running task in the background is
11:25 in a computer that contains multiple
11:29 CPUs the long-running task here might
11:32 actually be running on its own CPU which
11:34 is a different CPU than the one
11:39 executing the main UI thread and thus we
11:41 might start the action here like this is
11:43 just a little bit of initialization then
11:46 the long-running task starts and because
11:49 this task is running on a different CPU
11:51 this thread is running in a different on
11:54 a different CPU the main UI thread can
11:58 continued undisturbed on the other CPU
12:02 or the its own CPU which is executing
12:05 this thread up here so now the
12:07 long-running task is actually executing
12:10 at the exact same time as the main UI
12:15 thread is continuing to respond to input
12:17 from the user
12:20 as you can see multi-threading is really
12:22 beneficial to us in computer programming
12:25 however it is not without its problems
12:27 without its issues that we need to learn
12:31 how to handle first of all the the first
12:34 model that appeared for concurrency was
12:36 this yet mutable state model in which
12:38 threads could read and write the same
12:42 memory inside of the application however
12:45 this type of concurrency model leads to
12:48 possible race conditions invisible
12:50 rights and when you try to fix those two
12:52 you can get congestion
12:54 deadlock nested monitor lockout
12:56 starvation slip signals miss signals and
13:00 a lot of other things to solve these
13:03 problems either you can solve them with
13:05 some constructs that help you handle
13:07 these problems or you can completely
13:09 change the concurrency models who are no
13:12 shared mutable state concurrency model
13:15 and exams of such models are separate
13:17 state concurrency where the threads are
13:19 only communicating with
13:20 with messages they don't share any
13:24 actual data inside the application um
13:27 they don't share access to any writable
13:29 state in the application you have
13:31 functional parallelism and parallel
13:34 pipelines etc I will not get into
13:36 further detail about either these
13:39 problems are these concurrency models in
13:42 this video but if you check out the
13:44 description below the video you will
13:46 find a link to the playlist my Java
13:50 concurrency playlist and the videos in
13:53 that playlist will explore some of these
13:57 concepts in more detail and additionally
13:59 if you find if you check out the
14:00 description below the video you will
14:02 also find links to my textual versions
14:05 of these tutorials which will cover many
14:08 of the same topics as the videos but
14:09 sometimes the texts are a little bit
14:14 ahead of the videos that's all for this
14:16 introduction to Java concurrency and
14:17 multi-threading if you liked the video
14:19 hit the like button and don't forget to
14:20 check out the description below the
14:23 video for a link to the full playlist
14:26 with all the videos about Java
14:28 concurrency and if you want to see more
14:30 videos like this so why not subscribe to
