WEBVTT 1 00:00:00.080 --> 00:00:02.399 Every time you run a Java app that you know, 2 00:00:02.480 --> 00:00:05.080 pulls data from a network, updates a user interface, and 3 00:00:05.200 --> 00:00:07.719 writes to a database, all at the exact same time. 4 00:00:08.599 --> 00:00:14.000 You're relying on this this incredibly high stakes traffic control system, 5 00:00:14.640 --> 00:00:17.079 and it's operating at the microsecond. 6 00:00:16.519 --> 00:00:19.079 Level, right, Yeah, it's happening so fast we just completely 7 00:00:19.120 --> 00:00:20.079 ignore it exactly. 8 00:00:21.039 --> 00:00:24.280 So today we are diving straight into the rulebook for 9 00:00:24.320 --> 00:00:27.800 that infrastructure. We're looking at excerpts from the Java nine 10 00:00:27.839 --> 00:00:32.280 Concurrency Cookbook by Javier Fernandez Gonzales. 11 00:00:31.839 --> 00:00:34.399 Which is a fantastic resource by the way. 12 00:00:34.439 --> 00:00:37.479 Oh. Absolutely. The mission for this deep dive is to 13 00:00:37.560 --> 00:00:41.679 extract those core aha moments about multitasking and code. We 14 00:00:41.759 --> 00:00:45.520 want to understand how systems share resources, prevent deadlocks, and 15 00:00:45.679 --> 00:00:48.640 you know, avoid just totally corrupting data when thousands of 16 00:00:48.679 --> 00:00:49.719 operations collide. 17 00:00:50.000 --> 00:00:52.560 It really is a complex logistical operation. I mean, we 18 00:00:52.640 --> 00:00:55.759 just take for granted that a background thread downloading a 19 00:00:55.799 --> 00:00:59.000 file isn't going to somehow you know, overwrite the memory 20 00:00:59.039 --> 00:01:00.960 space being used by the front end interface. 21 00:01:01.000 --> 00:01:02.560 Yeah, that would be a disaster. 22 00:01:02.600 --> 00:01:07.519 Total disaster. So understanding how it all works requires breaking 23 00:01:07.560 --> 00:01:10.719 down how the operating system and the Java virtual machine 24 00:01:11.280 --> 00:01:14.400 actually manage execution behind the scenes. 25 00:01:14.159 --> 00:01:16.599 Right, And I think that starts with distinguishing between the 26 00:01:16.640 --> 00:01:21.560 illusion of simultaneous execution and well, actual simultaneous execution. 27 00:01:21.680 --> 00:01:24.120 Concurrency versus parallelism. 28 00:01:23.560 --> 00:01:27.560 Exactly because in an older single core processor, the system 29 00:01:27.680 --> 00:01:31.799 is executing concurrently, but it's not actually parallel. It's time slicing. 30 00:01:31.959 --> 00:01:32.840 Yeah, it's a NAT trick. 31 00:01:33.000 --> 00:01:35.879 It is. The OS scheduler is pulling one task onto 32 00:01:35.920 --> 00:01:38.640 the CPU, letting it run for a tiny fraction of 33 00:01:38.640 --> 00:01:41.239 a millisecond, saving its state, and then swapping in the 34 00:01:41.280 --> 00:01:41.719 next task. 35 00:01:41.920 --> 00:01:45.319 And that context switching happens so incredibly fast that human 36 00:01:45.359 --> 00:01:48.640 perception just registers it as simultaneous. You think it's happening 37 00:01:48.640 --> 00:01:49.640 at the same time, but it's not. 38 00:01:49.879 --> 00:01:51.840 Okay, let's unpack this for a second. It's kind of 39 00:01:51.879 --> 00:01:55.920 like a chef in a kitchen. Concurrency is one chef 40 00:01:56.040 --> 00:01:59.680 rapidly switching between chopping onions and stirring soup like chopster chopster, 41 00:02:00.280 --> 00:02:02.719 But parallelism is having two separate chefs. 42 00:02:02.959 --> 00:02:05.319 That's a great way to look at it. Because parallelism 43 00:02:05.599 --> 00:02:11.280 strictly requires a multicore architecture, you have multiple execution pipelines 44 00:02:11.599 --> 00:02:14.840 physically processing different instructions at the exact same. 45 00:02:14.759 --> 00:02:17.039 Clock cycle two actual chefs, right. 46 00:02:17.319 --> 00:02:20.599 But regardless of whether the hardware is single core or multicore, 47 00:02:21.280 --> 00:02:25.280 the software unit of execution within a Java process is the. 48 00:02:25.240 --> 00:02:27.919 Thread, and the source material really breaks down the fixed 49 00:02:27.960 --> 00:02:30.719 attributes of these threads, like you've got an immutable ID, 50 00:02:31.240 --> 00:02:33.879 a name, a status, and a priority level from one to. 51 00:02:33.840 --> 00:02:35.599 Ten, which is where a lot of people get tripped up. 52 00:02:35.639 --> 00:02:38.960 Oh for sure, because my immediate instinct as a developer, 53 00:02:39.000 --> 00:02:41.520 if I'm trying to optimize a critical path is to 54 00:02:41.639 --> 00:02:44.319 just assign my most important thread a priority of ten 55 00:02:44.639 --> 00:02:46.280 and assume it'll preempt everything else. 56 00:02:46.439 --> 00:02:50.199 That is such a common assumption. But what's fascinating here 57 00:02:50.599 --> 00:02:53.520 is that the Java priority system is essentially just a hint. 58 00:02:53.639 --> 00:02:55.840 Wait, just a hint, Like it doesn't force it. 59 00:02:55.840 --> 00:02:59.199 Not at all. You are basically signaling to the underlying 60 00:02:59.240 --> 00:03:03.560 operating system, whether that's Linux, Windows, Mac, OS, whatever, that 61 00:03:03.960 --> 00:03:06.439 you'd prefer this thread to get more CPU time. 62 00:03:06.560 --> 00:03:07.520 Ah I see. 63 00:03:07.719 --> 00:03:11.919 However, the OS scheduler operates on its own internal algorithms. 64 00:03:12.439 --> 00:03:16.800 It has to balance your applications threads against system level processes, 65 00:03:16.960 --> 00:03:20.039 network interrupts, UI responsiveness. 66 00:03:19.280 --> 00:03:22.000 So it could just ignore my Priority ten completely. 67 00:03:22.199 --> 00:03:25.000 Yep, it might throttle your priority ten thread if it 68 00:03:25.039 --> 00:03:28.599 detects that a Priority five thread has been starved of 69 00:03:28.680 --> 00:03:31.960 CPU cycles for too long. It's a recommendation, not an 70 00:03:32.039 --> 00:03:33.000 absolute mandate. 71 00:03:33.159 --> 00:03:35.240 That makes a lot of sense. Actually, the OS has 72 00:03:35.319 --> 00:03:40.439 to prioritize system stability over one specific Java apps request exactly, 73 00:03:40.599 --> 00:03:42.319 So we also need to look at how these threads 74 00:03:42.319 --> 00:03:46.080 are managed in their life cycle. The source outlines six states. 75 00:03:46.240 --> 00:03:51.159 You've got new, runnable, blocked, waiting, timed, waiting, and terminated. 76 00:03:51.639 --> 00:03:54.719 And the distinction that seems most critical for performance tuning, 77 00:03:54.840 --> 00:03:57.800 especially when things go wrong, is between blocked. 78 00:03:57.439 --> 00:04:00.560 And waiting, because both mean the thread is an executing right, 79 00:04:00.599 --> 00:04:02.039 but the mechanical reasons are different. 80 00:04:02.120 --> 00:04:05.400 Yeah, totally different, And this distinction dictates how you debug 81 00:04:05.400 --> 00:04:09.439 a bottleneck. A thread enters the block state entirely against 82 00:04:09.479 --> 00:04:10.159 its will. 83 00:04:10.039 --> 00:04:11.560 Like it hit a wall exactly. 84 00:04:12.080 --> 00:04:14.479 It needs to access a memory space or a block 85 00:04:14.479 --> 00:04:18.199 of code that is currently locked by another thread, so 86 00:04:18.240 --> 00:04:20.439 it just has to sit in the queue, burning no 87 00:04:20.560 --> 00:04:23.759 CPU cycles, just waiting for the OS to wake it 88 00:04:23.879 --> 00:04:25.759 up when the lock is finally released. 89 00:04:25.879 --> 00:04:26.959 But waiting is different. 90 00:04:27.279 --> 00:04:31.720 Waiting is a cooperative state. A thread intentionally puts itself 91 00:04:31.759 --> 00:04:34.480 into a waiting state because it's reached a point where 92 00:04:34.519 --> 00:04:38.120 it literally cannot proceed until a specific condition. 93 00:04:37.879 --> 00:04:40.199 Is met, like waiting for data to arrive over a 94 00:04:40.240 --> 00:04:40.959 network socket. 95 00:04:41.040 --> 00:04:43.399 Spot on. Yeah, and it will only wake up when 96 00:04:43.399 --> 00:04:45.920 another thread sends it a deliberate signal. 97 00:04:45.720 --> 00:04:48.959 Which brings up the broader concept of thread cooperation, which 98 00:04:49.000 --> 00:04:52.079 I find super interesting, especially when it comes to shutting 99 00:04:52.120 --> 00:04:52.560 them down. 100 00:04:52.720 --> 00:04:54.480 Oh yeah, thread termination is. 101 00:04:54.480 --> 00:04:57.360 Tricky because to start a thread you just explicitly call 102 00:04:57.480 --> 00:05:00.600 the start method. Easy. But stop them. You don't just 103 00:05:00.639 --> 00:05:02.360 kill a thread. You call interrupt, right. 104 00:05:02.279 --> 00:05:04.560 Which just sets a boolean flag on the thread. 105 00:05:04.879 --> 00:05:08.160 Yeah, the thread itself has to actively check this is 106 00:05:08.279 --> 00:05:11.560 interrupted flag, and if it's true, it throws an interrupted exception. 107 00:05:11.879 --> 00:05:14.439 So my question is, if a thread is stuck in 108 00:05:14.480 --> 00:05:18.079 an infinite loop, why not just have the JVM ruthlessly 109 00:05:18.199 --> 00:05:19.480 terminate the OS thread? 110 00:05:19.560 --> 00:05:19.680 Like? 111 00:05:20.240 --> 00:05:21.199 Why ask politely? 112 00:05:21.560 --> 00:05:25.639 Because ruthless termination at the OS level leads the application 113 00:05:25.720 --> 00:05:29.040 in an unpredictable, often completely corrupted state. 114 00:05:29.120 --> 00:05:29.959 Okay, corrupted? 115 00:05:30.000 --> 00:05:33.199 How well? Imagine a thread is midway through a complex 116 00:05:33.279 --> 00:05:37.759 database transaction, or it's currently holding a critical lock on 117 00:05:37.800 --> 00:05:41.000 some shared memory. If the JVM just kills it instantly, 118 00:05:41.040 --> 00:05:42.240 that lock is never released. 119 00:05:42.360 --> 00:05:45.319 Oh wow, so any other thread waiting for that lock 120 00:05:45.399 --> 00:05:47.360 is now permanently blocked forever. 121 00:05:47.879 --> 00:05:51.079 It's a disaster. By using the interruption mechanism, you force 122 00:05:51.160 --> 00:05:54.000 the thread to catch the exception, execute its finely blocks, 123 00:05:54.040 --> 00:05:58.079 close open file descriptors, roll back incomplete transactions, release its locks, 124 00:05:58.079 --> 00:06:00.000 and then exit the execution stack cleanly. 125 00:06:00.240 --> 00:06:03.199 Okay, so it's a highly controlled shutdown protocol to protect 126 00:06:03.240 --> 00:06:05.759 the memory state. That makes perfect sense. But there is 127 00:06:05.800 --> 00:06:08.600 an exception to how the JVM handles thread life cycles. Right. 128 00:06:09.000 --> 00:06:10.759 Demon threads, ah yeah. 129 00:06:11.199 --> 00:06:14.360 Demon threads operate under a totally different set of rules. 130 00:06:14.560 --> 00:06:18.199 They're strictly background service providers. The classic example in the 131 00:06:18.199 --> 00:06:20.759 text is a cleaner task that just runs in an 132 00:06:20.800 --> 00:06:24.439 infinite loop, sweeping a queue and deleting events older than 133 00:06:24.480 --> 00:06:25.199 ten seconds. 134 00:06:25.240 --> 00:06:27.399 Right, And because it's an infinite loop, you'd think it 135 00:06:27.399 --> 00:06:29.160 would keep the application running forever. 136 00:06:29.759 --> 00:06:33.279 But if it's flagged as a demon thread, the JVM 137 00:06:33.480 --> 00:06:36.959 just doesn't care. Once all the primary user threads have 138 00:06:37.040 --> 00:06:40.360 finished their work and terminated, the JVM will just abruptly 139 00:06:40.399 --> 00:06:43.439 halt and exit, taking the demon threads down with it. 140 00:06:43.759 --> 00:06:46.399 Yeah, their existence is only justified by the presence of 141 00:06:46.480 --> 00:06:50.000 user threads. Once the user threads are gone, the JVM 142 00:06:50.079 --> 00:06:52.519 doesn't wait for demon threads to reach a clean state. 143 00:06:52.959 --> 00:06:55.600 It just initiates the shutdown sequence immediately. 144 00:06:55.839 --> 00:06:57.959 Okay, so we've got all these user threads and demon 145 00:06:58.000 --> 00:07:01.480 threads executing concurrently, constantly being swapped in and out by 146 00:07:01.480 --> 00:07:04.920 the OS scheduler. This leads directly to the core problem 147 00:07:05.000 --> 00:07:08.319 of concurrency, which is shared resources and race. 148 00:07:08.120 --> 00:07:09.879 Conditions the danger zone. 149 00:07:10.079 --> 00:07:13.759 Yes, the source uses this parking garage simulation that I love. 150 00:07:14.160 --> 00:07:17.720 So imagine we have sensors at different gates tracking vehicles entering, 151 00:07:18.040 --> 00:07:22.199 and they are all updating a single short variable called cash. 152 00:07:21.800 --> 00:07:24.360 Right to track the money. And to understand why this 153 00:07:24.480 --> 00:07:27.839 fails without concurrency controls, you have to look at what 154 00:07:27.879 --> 00:07:29.480 happens beneath the Java code. 155 00:07:29.600 --> 00:07:32.680 Because a simple operation like cash equals cash plus two 156 00:07:32.920 --> 00:07:35.839 is not a single atomic instruction for the CPU, is it. 157 00:07:36.120 --> 00:07:38.759 No, not at all. It's a multi step process. At 158 00:07:38.759 --> 00:07:41.680 the hardware level. The CPU has to fetch the current 159 00:07:41.759 --> 00:07:45.040 value of cash from main memory into a local CPU register, 160 00:07:45.680 --> 00:07:48.519 then it increments the value in that register. 161 00:07:48.360 --> 00:07:51.560 And then Finally, it writes that updated value back to 162 00:07:51.680 --> 00:07:52.759 main memory. 163 00:07:52.480 --> 00:07:55.079 Exactly, and that multi step reality is where the race 164 00:07:55.120 --> 00:07:55.839 condition lives. 165 00:07:55.920 --> 00:07:57.360 Okay, wap me through it all right. 166 00:07:57.519 --> 00:08:00.800 Imagine sensor A and censor B both detect a car 167 00:08:01.000 --> 00:08:04.199 at nearly the exact same microsecond. The OS scheduler gives 168 00:08:04.199 --> 00:08:07.040 censor A a time slice. It fetches the cash value 169 00:08:07.079 --> 00:08:09.360 let's say it's one hundred dollars into its register. Right, 170 00:08:09.680 --> 00:08:12.360 but before it can increment and write back it's time 171 00:08:12.399 --> 00:08:15.040 slice expires, a context switch happens. 172 00:08:15.279 --> 00:08:19.000 Oh man, So the OS saves censor a's state and 173 00:08:19.040 --> 00:08:20.120 swaps in censor B. 174 00:08:20.360 --> 00:08:23.560 Yep, and censor B fetches the cash value, which is 175 00:08:23.600 --> 00:08:26.240 still one hundred in main memory because sensor A never 176 00:08:26.319 --> 00:08:29.040 updated it sinceor B increments it to one oh two 177 00:08:29.240 --> 00:08:30.000 and writes it back. 178 00:08:30.160 --> 00:08:32.399 Okay, so main memory is now one hundred and two. 179 00:08:32.639 --> 00:08:36.360 Right, then another context switch happens. Sensor A resumes exactly 180 00:08:36.360 --> 00:08:39.159 where it left off, with one hundred in its local register. 181 00:08:39.480 --> 00:08:41.840 Oh no, so it increments one hundred and two and 182 00:08:41.879 --> 00:08:43.240 writes one hundred and two back to. 183 00:08:43.200 --> 00:08:46.679 Main memory, completely overwriting censor b's work. You just lost 184 00:08:46.720 --> 00:08:47.320 two dollars. 185 00:08:47.440 --> 00:08:51.360 That is wild the book actually stimulates eight sensors processing 186 00:08:51.399 --> 00:08:54.919 thirty vehicles each at two dollars vehicle. The mathematical certainty 187 00:08:55.000 --> 00:08:56.399 is four hundred and eighty dollars. 188 00:08:56.440 --> 00:08:59.279 But because of those inner leaved hardware instructions, running it 189 00:08:59.279 --> 00:09:01.960 without rules give you four hundred and fifty eight or 190 00:09:02.039 --> 00:09:04.799 four sixty two, you're just silently losing data. 191 00:09:04.840 --> 00:09:07.200 And imagine if this wasn't a parking garage but your 192 00:09:07.200 --> 00:09:10.279 bank account processing simultaneous deposits and withdrawals. 193 00:09:10.360 --> 00:09:12.320 Yeah, that's when it stops being a fun simulation and 194 00:09:12.360 --> 00:09:13.639 becomes a massive liability. 195 00:09:13.919 --> 00:09:17.879 Seriously. So, the fundamental fixed Java provides for this is 196 00:09:17.919 --> 00:09:21.000 the synchronized keyword. It turns a block of code into 197 00:09:21.080 --> 00:09:24.879 a critical section. You use an object reference like usually. 198 00:09:24.600 --> 00:09:26.840 This as a monitor lock, right, like a key to 199 00:09:26.879 --> 00:09:27.240 a room. 200 00:09:27.440 --> 00:09:30.600 Exactly, if a thread wants to execute that code, it 201 00:09:30.720 --> 00:09:33.360 must acquire the lock. If it has the lock, no 202 00:09:33.440 --> 00:09:37.600 other thread can enter. It forces that multi step fetch 203 00:09:37.720 --> 00:09:41.000 increment right process to happen atomically. 204 00:09:40.480 --> 00:09:43.080 Which is great. It resolves the data corruption. Correctness always 205 00:09:43.080 --> 00:09:47.080 has to be prioritized over performance. But and this is 206 00:09:47.120 --> 00:09:50.840 a big but, it introduces a severe performance penalty. 207 00:09:50.559 --> 00:09:54.360 Right because synchronized is such a blunt instrument, very blunt. 208 00:09:54.440 --> 00:09:56.759 When you use it, you're using a very rigid, mutually 209 00:09:56.759 --> 00:09:59.639 exclusive lock. If you have ten threads hitting that method, 210 00:09:59.679 --> 00:10:01.639 one g it's the CPU time to execute, and the 211 00:10:01.639 --> 00:10:03.919 other nine are forced into that blsake state we. 212 00:10:03.879 --> 00:10:05.759 Talked about earlier, just sitting there waiting. 213 00:10:05.840 --> 00:10:08.960 Yeah, they're descheduled by the OS, moved into a weight queue, 214 00:10:09.080 --> 00:10:11.279 and then they have to endure the overhead of being 215 00:10:11.320 --> 00:10:14.440 woken up and rescheduled later. You essentially destroy the throughput 216 00:10:14.440 --> 00:10:15.240 of your application. 217 00:10:15.600 --> 00:10:19.679 You're forcing a concurrent system to operate sequentially, and because 218 00:10:19.679 --> 00:10:22.480 it puts so many threads to sleep, Java had to 219 00:10:22.519 --> 00:10:28.039 evolve better traffic signals, which brings us to advanced locks right. 220 00:10:28.120 --> 00:10:32.120 Moving beyond the native synchronized keyword using the lock interface, 221 00:10:32.759 --> 00:10:35.360 specifically implementations like re entrant lock. 222 00:10:36.000 --> 00:10:38.559 So how does re entrent lock fix the bluntness. 223 00:10:38.840 --> 00:10:42.840 Well, it provides programmatic flexibility. For example, it introduces the 224 00:10:42.840 --> 00:10:43.480 concept of. 225 00:10:43.440 --> 00:10:46.240 Fairness, fairness like polite threads. 226 00:10:46.399 --> 00:10:50.039 Basically, yeah, by default, locks in Java are non fair. 227 00:10:50.559 --> 00:10:52.919 When a lock is released, the OS doesn't care which 228 00:10:52.960 --> 00:10:55.120 block thread has been waiting the longest. It just wakes 229 00:10:55.120 --> 00:10:57.799 one up randomly, often based on whichever is most convenient 230 00:10:57.840 --> 00:10:58.799 for the CPU cash. 231 00:10:58.879 --> 00:11:01.080 But with reintrent lock you can pass a true boole 232 00:11:01.159 --> 00:11:04.720 into the constructor to enforce a fair lock. The textbook 233 00:11:04.799 --> 00:11:06.679 uses a print que as an example. 234 00:11:06.320 --> 00:11:09.360 Which is a perfect example because you absolutely want jobs 235 00:11:09.399 --> 00:11:11.360 processed in the order they were submitted, right. 236 00:11:11.559 --> 00:11:14.360 A fair lock forces the system to maintain a strict 237 00:11:14.399 --> 00:11:17.519 first in, first out queue of waiting threads, like a 238 00:11:17.519 --> 00:11:19.000 polite line at a coffee shop. 239 00:11:19.120 --> 00:11:22.919 There's a trade off, though, maintaining that strict queue adds overhead. 240 00:11:23.759 --> 00:11:27.120 The system has to track thread arrival times and orchestrate 241 00:11:27.159 --> 00:11:32.320 the wakeups in exact order. That lowers overall throughput compared 242 00:11:32.320 --> 00:11:35.039 to a non fare lock, where the OS can just 243 00:11:35.120 --> 00:11:36.399 optimize for raw speed. 244 00:11:36.559 --> 00:11:39.399 Got it, But even with re entrent lock, we still 245 00:11:39.399 --> 00:11:42.679 have the mutual exclusion problem. Right, Only one thread gets 246 00:11:42.679 --> 00:11:43.320 in at a time. 247 00:11:43.399 --> 00:11:43.720 Correct. 248 00:11:43.960 --> 00:11:45.919 So if we have a data structure that is read 249 00:11:46.080 --> 00:11:49.799 frequently but updated rarely, locking out all the readers just 250 00:11:49.840 --> 00:11:53.519 because one thread is currently reading seems incredibly inefficient. 251 00:11:53.559 --> 00:11:56.840 Well, it is because multiple threads reading a variable doesn't 252 00:11:56.879 --> 00:11:59.919 cause a race condition. Nobody is writing new data back 253 00:11:59.960 --> 00:12:01.600 to memory, right, and. 254 00:12:01.519 --> 00:12:03.759 That realization led to the read right lock, Yeah, which 255 00:12:03.799 --> 00:12:04.039 is a. 256 00:12:04.000 --> 00:12:07.080 Huge step up. It mathematically separates a lock into two 257 00:12:07.159 --> 00:12:11.600 distinct entities. Multiple threads can acquire the read lock simultaneously. 258 00:12:10.879 --> 00:12:14.039 So the system just keeps a counter of active readers exactly. 259 00:12:14.080 --> 00:12:16.799 As long as there are readers, the read lock remains open. 260 00:12:17.159 --> 00:12:19.759 But if a thread wants to modify the data, it 261 00:12:19.840 --> 00:12:20.960 requests the right lock. 262 00:12:21.320 --> 00:12:23.600 And what happens then? Do the readers get kicked out? 263 00:12:23.919 --> 00:12:27.360 No, the read right lock stops admitting new readers. It 264 00:12:27.440 --> 00:12:30.399 waits for the current active readers to finish and drop 265 00:12:30.440 --> 00:12:33.399 that counter to zero, and then it grants exclusive access 266 00:12:33.399 --> 00:12:33.799 to the writer. 267 00:12:34.000 --> 00:12:37.279 Okay, and once the writ is complete, the doors open 268 00:12:37.320 --> 00:12:38.600 for readers again exactly. 269 00:12:38.679 --> 00:12:43.080 It massively improves throughput for read heavy operations. However, it 270 00:12:43.159 --> 00:12:46.919 introduces a new structural vulnerability. 271 00:12:46.240 --> 00:12:47.159 Writer starvation. 272 00:12:47.360 --> 00:12:50.519 Yeah. Writer's starvation is a real headache, right. 273 00:12:50.480 --> 00:12:53.080 Because if you have a high traffic system where hundreds 274 00:12:53.120 --> 00:12:56.240 of reader threads are constantly requesting the read lock, the 275 00:12:56.279 --> 00:12:59.679 active reader counter might never actually hit zero never, so 276 00:12:59.759 --> 00:13:02.639 the the right thread is essentially stuck in the queue forever, 277 00:13:02.799 --> 00:13:05.240 waiting for a break in the traffic that just never comes. 278 00:13:05.320 --> 00:13:10.000 Exactly and to resolve that specific bottleneck. Java eight introduce 279 00:13:10.080 --> 00:13:10.799 the stamplock. 280 00:13:11.000 --> 00:13:14.559 Oh, this is where it gets really interesting. Stamplock introduces 281 00:13:14.600 --> 00:13:18.080 this concept of optimistic reading, which honestly is one of 282 00:13:18.080 --> 00:13:21.039 the most advanced mechanics in the cookbook. What does it 283 00:13:21.080 --> 00:13:23.559 actually mean for code to be optimistic? 284 00:13:23.799 --> 00:13:26.840 It's a brilliant shift in strategy. Let's look at how 285 00:13:26.840 --> 00:13:30.360 it functions at the memory level. With the traditional lock, 286 00:13:30.679 --> 00:13:32.960 a thread has to write to a shared memory location 287 00:13:33.120 --> 00:13:36.840 to declare, hey, I hold this lock right. That right 288 00:13:36.960 --> 00:13:40.960 operation forces the CPU to invalidate caches across other cores, 289 00:13:41.399 --> 00:13:44.080 which is an incredibly expensive hardware operation just. 290 00:13:44.000 --> 00:13:45.480 To say I'm reading something right. 291 00:13:46.120 --> 00:13:50.080 The stamplock circumvents that entirely for reads. When a thread 292 00:13:50.080 --> 00:13:53.720 calls try optimistic read, it doesn't actually acquire a lock 293 00:13:53.840 --> 00:13:56.120 or alter the state of the lock in memory at all. 294 00:13:56.240 --> 00:13:57.440 Wait, it doesn't lock it. 295 00:13:57.600 --> 00:14:01.320 Nope. Instead, the stamplock we're it turns a stamp, a 296 00:14:01.360 --> 00:14:05.120 long integer that represents the current version or sequence number 297 00:14:05.159 --> 00:14:05.960 of the lock state. 298 00:14:06.039 --> 00:14:07.320 Okay, so it gets a stamp. 299 00:14:07.480 --> 00:14:10.720 Then what the thread takes that stamp reads the shared 300 00:14:10.759 --> 00:14:14.039 data into its own local private variables and then immediately 301 00:14:14.039 --> 00:14:16.480 calls a validate method passing in that stamp. 302 00:14:16.559 --> 00:14:19.519 Ah. So the validate method just checks if the internal 303 00:14:19.600 --> 00:14:22.519 version number of the stamplock has changed since the stamp 304 00:14:22.600 --> 00:14:23.399 was issued. 305 00:14:23.399 --> 00:14:26.600 Exactly if no other thread acquired a right lock in 306 00:14:26.639 --> 00:14:30.279 that tiny microsecond window while you were reading, the version 307 00:14:30.320 --> 00:14:33.679 number still matches. The validation returns true. 308 00:14:33.960 --> 00:14:37.279 Wow, so the thread successfully read the data without ever 309 00:14:37.320 --> 00:14:41.559 locking the system or causing cash invalidation across the CPU cores. 310 00:14:41.720 --> 00:14:45.000 Yep, it's a gamble. It's an assumption that collisions are rare. 311 00:14:45.399 --> 00:14:48.879 You move fast, copy the data, and validate after the fact. 312 00:14:48.960 --> 00:14:50.919 But what if you lose the gamble. What if a 313 00:14:50.960 --> 00:14:54.799 writer thread did acquire the right lock during your read operation, then. 314 00:14:54.759 --> 00:14:58.519 The lock's internal version number would have incremented. Your validation fails. 315 00:14:58.840 --> 00:15:00.159 It returns false. 316 00:15:00.120 --> 00:15:03.039 Because your local copy of the data is potentially corrupted 317 00:15:03.039 --> 00:15:03.879 by a partial rite. 318 00:15:04.519 --> 00:15:08.000 So in that scenario, your thread discards the local copy 319 00:15:08.039 --> 00:15:10.600 and falls back to a heavier traditional read lock to 320 00:15:10.679 --> 00:15:13.799 ensure it gets clean data. But in systems with massive 321 00:15:13.840 --> 00:15:16.759 read to write ratios, the optimistic gamble pays off so 322 00:15:16.919 --> 00:15:19.039 often that the performance gains are just huge. 323 00:15:19.120 --> 00:15:22.279 That is, so cool. It's a complete shift from pessimistic 324 00:15:22.279 --> 00:15:24.240 control to optimistic validation. 325 00:15:24.679 --> 00:15:25.279 It really is. 326 00:15:25.440 --> 00:15:25.759 Yeah. 327 00:15:25.879 --> 00:15:29.480 But up to this point, all these locks re entrant 328 00:15:29.799 --> 00:15:34.879 ReadWrite stamped in moorge. They are primarily about restricting access. 329 00:15:34.600 --> 00:15:35.600 Right, keeping threads out. 330 00:15:35.759 --> 00:15:39.840 Yeah, but the source material also dives into coordination. Sometimes 331 00:15:39.879 --> 00:15:43.039 threads don't just need exclusive access, They need to orchestrate 332 00:15:43.080 --> 00:15:44.720 complex handoffs. 333 00:15:44.440 --> 00:15:49.320 Which brings us to advanced coordination. And the foundational scenario 334 00:15:49.399 --> 00:15:51.600 here is the producer consumer. 335 00:15:51.240 --> 00:15:54.559 Problem write a classic computer science problem. You have a 336 00:15:54.600 --> 00:15:58.159 shared data buffer. Producer threads compute data and insert it. 337 00:15:58.320 --> 00:16:00.879 Consumer threads extract data and process it. 338 00:16:01.120 --> 00:16:03.679 But they have to communicate right, Because if the buffer 339 00:16:03.799 --> 00:16:07.480 is full, a producer shouldn't just repeatedly pull the buffer 340 00:16:07.480 --> 00:16:10.039 in a while loop, constantly checking if they're space No. 341 00:16:10.159 --> 00:16:13.679 That's called spin waiting. It's terrible for performance. It burns 342 00:16:13.679 --> 00:16:16.120 CPU cycles on a core that could actually be used 343 00:16:16.120 --> 00:16:18.000 by a consumer thread to empty the buffer. 344 00:16:18.080 --> 00:16:20.000 So how do we fix spinwaighting? 345 00:16:20.159 --> 00:16:23.360 Java provides the condition interface for this, usually paired with 346 00:16:23.360 --> 00:16:26.320 a reentrant lock. When a producer sees a full buffer, 347 00:16:26.440 --> 00:16:29.919 it calls a weight on a specific condition object. 348 00:16:29.559 --> 00:16:30.679 And that puts it to sleep. 349 00:16:31.039 --> 00:16:34.679 Yes, the os de schedules the thread puts it in 350 00:16:34.720 --> 00:16:38.720 a waiting state, and crucially, it atomically releases the lock 351 00:16:39.120 --> 00:16:40.720 so consumers can actually get in. 352 00:16:40.919 --> 00:16:44.759 Oh that's elegant. So then a consumer thread acquires the lock, 353 00:16:44.879 --> 00:16:47.480 pulls an item from the buffer, and it needs to 354 00:16:47.480 --> 00:16:48.600 tell the producer right right. 355 00:16:48.679 --> 00:16:52.000 It calls signal on that exact same condition object. 356 00:16:51.879 --> 00:16:54.200 And that triggers the os scheduler to wake up the 357 00:16:54.200 --> 00:16:57.480 sleeping producer threads, letting them know, hey, the state changed 358 00:16:57.679 --> 00:16:59.440 space is available exactly. 359 00:16:59.480 --> 00:17:02.639 It's a high maily efficient event driven handoff instead of 360 00:17:02.639 --> 00:17:03.559 constantly checking. 361 00:17:03.679 --> 00:17:07.039 Okay, so that's handoffs. But this coordination also extends to 362 00:17:07.200 --> 00:17:11.880 managing pools of identical resources, which brings us to semaphores, 363 00:17:12.119 --> 00:17:15.920 originally invented by Edsgerdikstra back in what nineteen sixty five. 364 00:17:16.000 --> 00:17:18.039 Yeah, they've been around for a while. Because a lock 365 00:17:18.119 --> 00:17:21.039 is binary, it's either held or it isn't. But a 366 00:17:21.079 --> 00:17:24.079 semaphore is a counter representing a finite number of permits. 367 00:17:24.119 --> 00:17:26.799 The book uses a multiprinter queue to illustrate this, but 368 00:17:26.839 --> 00:17:29.000 it kind of reminds me the bouncer at a club. 369 00:17:29.200 --> 00:17:31.759 Oh I like that? How so well, a lock. 370 00:17:31.680 --> 00:17:35.039 Is like a VIP bathroom, one person in, one person out, 371 00:17:35.680 --> 00:17:38.759 but a semaphore is a bouncer keeping the club capacity 372 00:17:38.759 --> 00:17:40.200 at exactly three people. 373 00:17:40.400 --> 00:17:43.119 That's a great analogy. So if you have three physical printers, 374 00:17:43.440 --> 00:17:45.839 you initialize a semaphore with a permit count of. 375 00:17:45.839 --> 00:17:48.319 Three, and when a thread wants to print, it calls 376 00:17:48.359 --> 00:17:48.799 a choir. 377 00:17:49.000 --> 00:17:51.599 The semaphore checks the counter. If it's greater than zero, 378 00:17:52.000 --> 00:17:54.519 it decrements the counter and grants the permit, So. 379 00:17:54.519 --> 00:17:57.839 The first three threads get immediate access, dropping the counter 380 00:17:57.880 --> 00:17:58.359 to zero. 381 00:17:58.519 --> 00:18:01.200 Right when a fourth thread calls a CHOI. The semaphore 382 00:18:01.240 --> 00:18:04.720 sees that zero count, it blocks that four thread, puts 383 00:18:04.720 --> 00:18:06.200 it to sleep in a queue. 384 00:18:05.920 --> 00:18:08.000 Just waiting in line outside the club exactly. 385 00:18:08.079 --> 00:18:11.079 It stays there until one of the active threads finishes 386 00:18:11.119 --> 00:18:12.960 its print job and calls release. 387 00:18:12.880 --> 00:18:14.960 Which increments the counter back to one. 388 00:18:15.079 --> 00:18:17.559 Yes, and then the semaphore unblocks the next thread in 389 00:18:17.599 --> 00:18:20.839 the queue and hands it the newly available permit. It 390 00:18:20.880 --> 00:18:24.759 regulates capacity without caring about the specific identity of the 391 00:18:24.799 --> 00:18:25.640 threads inside. 392 00:18:25.880 --> 00:18:29.039 It's just brilliant. But I mean this raises an important question. 393 00:18:29.200 --> 00:18:33.200 While these tools locks conditions semaphors, they give you the 394 00:18:33.279 --> 00:18:37.920 power to organize chaos, don't They also introduce a massive vulnerability. 395 00:18:38.119 --> 00:18:39.079 Oh you mean deadlocks? 396 00:18:39.200 --> 00:18:42.440 Yeah, deadlocks the ultimate concurrency nightmare, they really are. 397 00:18:42.759 --> 00:18:46.000 This happens when the coordination logic loops back on itself. 398 00:18:45.680 --> 00:18:47.680 The circular dependency exactly. 399 00:18:48.119 --> 00:18:52.039 Imagine thread A acquires lock x at the exact same 400 00:18:52.079 --> 00:18:54.279 time thread B acquires lock y. 401 00:18:54.599 --> 00:18:54.960