WEBVTT 1 00:00:00.080 --> 00:00:03.160 You know that feeling right, that pressure just before a 2 00:00:03.160 --> 00:00:07.120 big professional interview, especially somewhere like Java. It's such a 3 00:00:07.200 --> 00:00:08.279 dynamic field. 4 00:00:08.400 --> 00:00:09.359 Oh yeah, definitely. 5 00:00:09.400 --> 00:00:11.599 It's really not just about whether you know the syntax, 6 00:00:11.679 --> 00:00:12.519 is it not at all. 7 00:00:12.960 --> 00:00:13.720 It's much deeper. 8 00:00:13.839 --> 00:00:17.679 It's understanding the core ideas, the architecture underneath it all, 9 00:00:17.719 --> 00:00:21.600 and maybe surprisingly those non technical bits that can really 10 00:00:21.640 --> 00:00:22.559 make you stand. 11 00:00:22.320 --> 00:00:24.160 Out exactly the human element. 12 00:00:24.440 --> 00:00:27.480 Welcome to the deep dive today. We're diving into a 13 00:00:27.519 --> 00:00:32.600 really practical resource, Java Professional Interview Guide by Mandar maheshwar 14 00:00:32.799 --> 00:00:36.119 Jog mm hm. And our goal here isn't just you know, 15 00:00:36.679 --> 00:00:38.359 listing questions and answers. 16 00:00:38.439 --> 00:00:39.320 Oh, that's not the point. 17 00:00:39.439 --> 00:00:41.560 We want to pull out the key insights, the whyse 18 00:00:41.719 --> 00:00:44.399 behind the what's maybe even some unexpected stuff that really 19 00:00:44.399 --> 00:00:48.079 makes you well informed, well prepared for that Java interview. 20 00:00:48.320 --> 00:00:51.840 Think of it as getting up to speed quickly but 21 00:00:51.920 --> 00:00:53.039 properly with. 22 00:00:53.039 --> 00:00:55.799 Stepth exactly, getting that real understanding. 23 00:00:56.039 --> 00:00:59.079 That's the plan. We're going beyond just definitions, looking at 24 00:00:59.079 --> 00:01:03.240 the practical side, the strategy that Mandar's guide really highlights, and. 25 00:01:03.200 --> 00:01:07.439 Where better to start than, maybe counterintuitively, the human side 26 00:01:07.439 --> 00:01:10.000 of it all. The interview process itself. 27 00:01:10.280 --> 00:01:15.120 Right, because just being technically brilliant, Yeah, it's often not 28 00:01:15.280 --> 00:01:15.799 enough as. 29 00:01:15.719 --> 00:01:21.079 It rarely guarantees the job. No, the guide really emphasizes 30 00:01:21.159 --> 00:01:23.760 setting the stage, those non technical things you need to 31 00:01:23.840 --> 00:01:26.159 navigate just to get to the technical part. Yeah, Like, 32 00:01:26.359 --> 00:01:28.599 how do you even find these Java opportunities in the 33 00:01:28.599 --> 00:01:30.439 first place? What does a guide say about that? 34 00:01:30.599 --> 00:01:33.159 Well, it boils down to two main routes. Typically, you've 35 00:01:33.159 --> 00:01:37.480 got your on campus recruitment okay, which often focuses more 36 00:01:37.480 --> 00:01:41.200 on aptitude, maybe some CC plus plus R your grades, 37 00:01:41.239 --> 00:01:44.359 that sort of thing generally a bit easier. Maybe. Then 38 00:01:44.359 --> 00:01:47.879 there's off campus that's usually through job portals, company websites, 39 00:01:48.280 --> 00:01:51.120 sometimes even those big walk in events a yeah, and 40 00:01:51.280 --> 00:01:54.079 these tend to be well technically tougher. So knowing that 41 00:01:54.200 --> 00:01:55.359 helps you kind of shape. 42 00:01:55.079 --> 00:01:57.400 Your prep and the range of roles once you're in. 43 00:01:58.000 --> 00:02:00.680 It's huge. The guide points us out really well, it 44 00:02:00.760 --> 00:02:02.959 really is. You could be a full stack dev front end, 45 00:02:02.959 --> 00:02:06.519 back end the works, or specialized as a Java web 46 00:02:06.519 --> 00:02:10.439 developer or obviously mobile apps, Android development being a big 47 00:02:10.439 --> 00:02:11.080 one for Java. 48 00:02:11.159 --> 00:02:12.199 Still huge. Yeah. 49 00:02:12.319 --> 00:02:16.240 Then there's the enterprise side Java E developers building those 50 00:02:16.319 --> 00:02:20.800 big scalable systems with things like spring Hibernate. 51 00:02:20.560 --> 00:02:22.400 Rest crucial roles, and. 52 00:02:22.360 --> 00:02:26.840 Increasingly Java API developers often using spring boot to build 53 00:02:26.840 --> 00:02:29.759 out those rest APIs that power everything. It's a really 54 00:02:29.840 --> 00:02:30.840 wide field. 55 00:02:30.680 --> 00:02:34.120 Absolutely, so once you found a role that fits, there's 56 00:02:34.159 --> 00:02:37.360 the selection process itself, like a pipeline, right. It often 57 00:02:37.439 --> 00:02:39.800 kicks off with a phone interview, could be a surprise 58 00:02:39.879 --> 00:02:43.080 call from HR, maybe scheduled, sometimes even a technical panel 59 00:02:43.159 --> 00:02:45.639 right off the bat, and a simple pip but honestly 60 00:02:45.919 --> 00:02:50.319 so important find a quiet place, no distractions. 61 00:02:50.520 --> 00:02:52.560 Sounds obvious, but easily forgotten in the moment. 62 00:02:52.639 --> 00:02:54.319 Totally first impressions count. 63 00:02:54.520 --> 00:02:57.080 So after that initial phone screen usually. 64 00:02:56.759 --> 00:02:59.680 Technical tests come next. The guide mentions two main flavors, 65 00:03:00.400 --> 00:03:02.960 multiple choice questions MCQs. You see those a lot non 66 00:03:03.039 --> 00:03:06.520 campus drives. They mix aptitude with technical stuff c C 67 00:03:06.680 --> 00:03:10.879 plus plus AID SQL Java right, and then algorithm based 68 00:03:10.879 --> 00:03:13.240 tests more focused problem solving. 69 00:03:13.479 --> 00:03:17.360 And the point is just efficiency. 70 00:03:16.960 --> 00:03:20.159 Pretty much, yeah, filtering candidates effectively before you get to 71 00:03:20.159 --> 00:03:22.800 the more intensive face to face interviews. 72 00:03:22.599 --> 00:03:25.639 Which leads us there the face to face what's the approach? 73 00:03:25.759 --> 00:03:27.240 Is there a standard way it goes? 74 00:03:27.759 --> 00:03:31.599 Not really a fixed rule, no, but often it builds 75 00:03:31.639 --> 00:03:34.400 on how you did in those technical tests. Make sense, 76 00:03:34.560 --> 00:03:38.080 But here's the key. They're really trying to understand your concepts, 77 00:03:38.360 --> 00:03:42.639 not just rope memorization, but can you apply it like well, 78 00:03:42.639 --> 00:03:45.120 say you're interviewing for a role involving I don't know 79 00:03:45.240 --> 00:03:49.639 a stock trading system, expect deep questions on concurrency. 80 00:03:49.879 --> 00:03:52.240 Ah, right, high stakes there exactly. 81 00:03:52.719 --> 00:03:55.120 Or if it's an e commerce site, they'll probe hard 82 00:03:55.280 --> 00:03:59.560 on database transactions, data consistency. It's about applying the knowledge 83 00:03:59.599 --> 00:04:00.680 to theext You know. 84 00:04:00.719 --> 00:04:02.599 What I found really refreshing in the guide, and it's 85 00:04:02.639 --> 00:04:04.879 something people stress about. Is the idea that it's okay 86 00:04:04.919 --> 00:04:06.039 not to know everything. 87 00:04:06.319 --> 00:04:08.280 Yes, that's such a crucial point. 88 00:04:08.360 --> 00:04:11.639 The advice is just accept it politely. Remember development is 89 00:04:11.680 --> 00:04:14.360 a team effort, right. We rely on collective knowledge. 90 00:04:14.479 --> 00:04:19.800 Absolutely. It shows humility, honesty, and that you understand how 91 00:04:19.839 --> 00:04:23.000 real teams work. It's not just about being the solo genius. 92 00:04:23.079 --> 00:04:26.319 It shifts the focus. Interviewers aren't just ticking boxes on 93 00:04:26.360 --> 00:04:27.360 technical knowledge. 94 00:04:27.519 --> 00:04:30.240 No, they're looking at the whole picture. Yeah, your job 95 00:04:30.319 --> 00:04:34.319 competence for sure? What projects have you actually done? What 96 00:04:34.439 --> 00:04:36.959 problems did you solve? How much effort did you put in, 97 00:04:37.040 --> 00:04:41.000 but also team fit hugely important. Yeah, would they actually 98 00:04:41.079 --> 00:04:43.160 enjoy working with you day to day? How are your 99 00:04:43.160 --> 00:04:46.319 interpersonal skills? Can you handle disagreements constructively? 100 00:04:46.360 --> 00:04:48.079 It's often the decider, isn't it. 101 00:04:47.879 --> 00:04:50.199 It really can be. And then there's learning agility. 102 00:04:50.279 --> 00:04:52.079 How quickly you pick things up exactly? 103 00:04:52.240 --> 00:04:55.959 Tech moves fast. Companies need people who can learn new tools, 104 00:04:56.040 --> 00:05:00.000 new frameworks quickly. They'll provide training, sure, but they expect 105 00:05:00.120 --> 00:05:01.399 you to become proficient fast. 106 00:05:01.720 --> 00:05:03.639 And the final piece trustworthiness. 107 00:05:04.439 --> 00:05:07.759 Fundamentally, are you a good team player? Are you reliable? 108 00:05:08.120 --> 00:05:11.279 Will you fit the culture? Once the technical side is cleared, 109 00:05:11.560 --> 00:05:12.600 this becomes critical. 110 00:05:12.879 --> 00:05:17.480 So the guide offers some mantras for success. Practical tips, Yeah. 111 00:05:17.360 --> 00:05:21.959 Some really good ones. Answer correctly obviously, but crucially in 112 00:05:22.040 --> 00:05:22.800 your own words. 113 00:05:23.000 --> 00:05:25.279 Ah, not just reciting definition. 114 00:05:24.959 --> 00:05:28.439 Right, give real examples, show it you understand it, don't 115 00:05:28.519 --> 00:05:32.959 just know it. And body language, project confidence, show your serious. 116 00:05:32.759 --> 00:05:34.480 And research the company essential. 117 00:05:34.920 --> 00:05:37.759 Know what they do, their products, their area. And this 118 00:05:37.800 --> 00:05:41.639 is a big one. Know your resume or CV inside out. 119 00:05:41.959 --> 00:05:45.360 Don't list skills you can't back up never, it's a killer. 120 00:05:45.480 --> 00:05:49.040 And speaking of resumes, the guide clarifies that CV versus 121 00:05:49.120 --> 00:05:51.240 resume distinction, which trips people up. 122 00:05:51.319 --> 00:05:54.720 Yeah, it's a good clarification. A CB curriculum VITA is 123 00:05:54.839 --> 00:05:59.439 usually for freshers, focuses on academics, projects, maybe publications. 124 00:05:59.000 --> 00:06:00.959 Your whole academic life basically, right. 125 00:06:00.839 --> 00:06:03.360 Whereas a resume is for experienced folks. It's about your 126 00:06:03.399 --> 00:06:07.600 career path, your roles, key achievement, certifications, different focus. Knowing 127 00:06:07.639 --> 00:06:09.759 which one to use is a small but important detail. 128 00:06:09.839 --> 00:06:12.920 Okay, so we've navigated the human side the process. Now 129 00:06:13.000 --> 00:06:16.079 let's get into the technical core, the Java itself. Where 130 00:06:16.079 --> 00:06:19.360 does the guide start with the architecture? How does Java 131 00:06:19.360 --> 00:06:20.519 code actually run? 132 00:06:20.839 --> 00:06:23.600 It starts right at the beginning. Your source code, the 133 00:06:23.639 --> 00:06:26.759 dot java file, what we write exactly. That gets fed 134 00:06:26.800 --> 00:06:31.319 into the compiler javac, which produces bytcode the dot class file. Okay, 135 00:06:31.399 --> 00:06:34.000 and that bytecode is what's executed by the Java Virtual 136 00:06:34.040 --> 00:06:37.959 Machine the JVM. That's the basic flow source to bytcode 137 00:06:38.000 --> 00:06:38.920 to JVM. 138 00:06:38.600 --> 00:06:42.279 Execution, and the guide highlights something specific in that flow, 139 00:06:42.319 --> 00:06:45.120 a kind of gatekeeper, the bytecode verifier. 140 00:06:45.279 --> 00:06:48.920 Yes, this is fascinating and often overlooked. It's a crucial 141 00:06:48.920 --> 00:06:49.800 security layer. 142 00:06:49.879 --> 00:06:53.000 Why is it needed if the compiler made the bit code. 143 00:06:53.360 --> 00:06:57.120 But here's the thing. Even after compilation, someone would say, 144 00:06:57.319 --> 00:07:00.800 assemblying knowledge could potentially modify that class fall they could 145 00:07:00.839 --> 00:07:04.000 try to sneak in malicious or just broken code. 146 00:07:04.079 --> 00:07:05.279 Right, okay, I see the. 147 00:07:05.199 --> 00:07:08.000 Bicode verifier acts as a guard. Before the JVM runs 148 00:07:08.000 --> 00:07:10.480 the code. It checks for things like is the operants 149 00:07:10.519 --> 00:07:14.480 dat consistent? Are variables initialized? Is code trying to access 150 00:07:14.480 --> 00:07:17.240 private data illegally? Our final rules being broken? 151 00:07:17.319 --> 00:07:19.639 So it's protecting the JVM itself from bad bytecode. 152 00:07:19.759 --> 00:07:22.839 Precisely, it ensures the bytecode adheres to the rules, keeping 153 00:07:22.879 --> 00:07:26.199 the runtime environment stable and secure. A really vital component. 154 00:07:26.519 --> 00:07:29.199 Vital, but maybe not something you think about daily. Now, 155 00:07:29.199 --> 00:07:33.920 those three acronyms that always come up, JVM, JR, JDK. 156 00:07:34.560 --> 00:07:36.079 Can we quickly nail down the difference? 157 00:07:36.160 --> 00:07:38.800 Sure, let's break it down. The JVM, the Java Virtual 158 00:07:38.839 --> 00:07:41.879 machine is the heart. It's the thing that actually runs 159 00:07:41.879 --> 00:07:44.879 the bit code. The runtime engine, got it engine, the JR, 160 00:07:45.199 --> 00:07:49.360 the Java runtime environment, the JVM plus all the standard 161 00:07:49.439 --> 00:07:52.959 libraries and files needed to actually run a Java application. 162 00:07:53.240 --> 00:07:55.040 If you just want to run a Java program, someone 163 00:07:55.079 --> 00:07:56.240 else wrote, you need the JR. 164 00:07:56.519 --> 00:07:58.959 Okay, JVM plus libraries, runtime. 165 00:07:58.639 --> 00:08:01.800 Exactly and the JDK, the Java Development Kit is the 166 00:08:01.839 --> 00:08:04.600 whole package for developers. It includes the JRE so you 167 00:08:04.600 --> 00:08:08.120 can run things, plus the development tools, the compiler, javact, 168 00:08:08.120 --> 00:08:09.319 the debugger, all that stuff. 169 00:08:09.399 --> 00:08:12.560 So jdk's for writing code, JRE is just for running it. 170 00:08:12.639 --> 00:08:14.680 That's the core distinction developed versus. 171 00:08:14.519 --> 00:08:20.079 Run perfect Now shifting to object oriented programming OOP. These 172 00:08:20.160 --> 00:08:23.600 are the absolute fundamentals of Java. The guide really pushes 173 00:08:23.639 --> 00:08:26.600 the why behind them. Let's start with encapsulation, the art 174 00:08:26.639 --> 00:08:30.199 of hiding. What's the real benefit beyond just private fields 175 00:08:30.199 --> 00:08:31.199 and public methods. 176 00:08:31.360 --> 00:08:35.279 It's really about control and maintainability. Sure, you hide internal 177 00:08:35.360 --> 00:08:39.480 data using private exposed behavior via public methods. 178 00:08:39.559 --> 00:08:41.320 But why Yeah, what's the payoff? 179 00:08:41.600 --> 00:08:45.240 It ensures the object maintains its integrity. The guide uses 180 00:08:45.240 --> 00:08:49.120 a rectangle example. Say width is set externally, but height 181 00:08:49.200 --> 00:08:53.440 is calculated internally. Maybe height with two. Okay, if height 182 00:08:53.480 --> 00:08:57.440 were public, someone could set it directly, breaking that internal logic, right, 183 00:08:57.840 --> 00:08:59.679 the rectangle wouldn't behave as intended. 184 00:09:00.039 --> 00:09:04.919 Ah, So encapsulation protects the object's internal consistency exactly. 185 00:09:05.080 --> 00:09:08.320 It lets the creator guarantee the object's behavior. Plus you 186 00:09:08.360 --> 00:09:11.440 can change the internal implementation later, maybe optimize how height 187 00:09:11.519 --> 00:09:14.120 is calculated and as long as the public methods don't change, 188 00:09:14.200 --> 00:09:16.600 nothing outside breaks. That's huge for maintenance. 189 00:09:16.720 --> 00:09:19.360 That makes sense, and that idea of how components interact 190 00:09:19.519 --> 00:09:22.480 leads us straight to coupling, doesn't it tight versus loose? 191 00:09:22.639 --> 00:09:24.799 Right? A really important concept for a larger systems. 192 00:09:24.879 --> 00:09:25.639 So take coupling. 193 00:09:26.200 --> 00:09:29.679 That's bad generally, yes, it means components are too dependent. 194 00:09:30.159 --> 00:09:33.679 If class A directly creates and calls methods on class B, 195 00:09:34.120 --> 00:09:36.679 a change in B, like renaming a method, breaks A. 196 00:09:37.440 --> 00:09:39.799 It creates ripples. Maintenance becomes a nightmare. 197 00:09:39.879 --> 00:09:42.440 Okay, So loose coupling is the goal. How does that work? 198 00:09:42.679 --> 00:09:46.240 With loose coupling components are independent. Class A might rely 199 00:09:46.320 --> 00:09:49.039 on an interface, let's say print, Then class B and 200 00:09:49.120 --> 00:09:52.639 class C can implement print. A just interacts with the 201 00:09:52.639 --> 00:09:54.320 print interface, not B or C. 202 00:09:54.399 --> 00:09:56.360 Directly, so A doesn't care if it's B or C 203 00:09:56.600 --> 00:09:57.879 doing the printing exactly. 204 00:09:58.240 --> 00:10:00.799 You can swap B for C without changing A. It 205 00:10:00.840 --> 00:10:03.919 gives you flexibility, makes the system easier to change and extend, 206 00:10:04.440 --> 00:10:05.840 vital for complex software. 207 00:10:06.000 --> 00:10:10.159 Makes perfect sense. Now, another classic OP interview question, abstract 208 00:10:10.200 --> 00:10:14.320 classes versus interfaces. What's the quick takeaway on when to use. 209 00:10:14.200 --> 00:10:18.200 Which key differences boil down to capabilities. An abstract class 210 00:10:18.240 --> 00:10:21.399 can have both abstract methods to be implemented by subclasses 211 00:10:21.639 --> 00:10:25.879 and concrete methods with implementation. It can have constructors data members, 212 00:10:26.080 --> 00:10:28.759 but Java only allows single inheritance from classes. 213 00:10:28.840 --> 00:10:31.480 Okay, so partial implementation possible, right. 214 00:10:31.840 --> 00:10:35.559 An interface traditionally only had abstract methods, though Java eight 215 00:10:35.600 --> 00:10:39.120 added default and static methods, blurring the lines a bit. Yeah, no, 216 00:10:39.279 --> 00:10:43.960 constructors can only declare constants. But crucially, a class can 217 00:10:44.000 --> 00:10:45.159 implement multiple. 218 00:10:44.840 --> 00:10:47.480 Interfaces multiple inheritance of type exactly. 219 00:10:47.559 --> 00:10:51.240 So abstract classes are often for is I relationships where 220 00:10:51.240 --> 00:10:54.399 you want to provide some base implementation interfaces. Define it 221 00:10:54.440 --> 00:10:56.320 can do contract or capability. 222 00:10:56.440 --> 00:10:59.679 Got it. Then there's polymorphism, the idea that you can 223 00:10:59.720 --> 00:11:03.399 refer to an object via its superclass or interface type. 224 00:11:03.919 --> 00:11:08.080 But the guide warns about a cosmic superclass. Payfall, what's 225 00:11:08.120 --> 00:11:08.879 that right? 226 00:11:09.000 --> 00:11:12.919 So technically every object in Java inherits from the object class. 227 00:11:13.320 --> 00:11:15.759 You can refer to any object using a variable. 228 00:11:15.440 --> 00:11:17.480 Of type object the cosmic superclass. 229 00:11:17.559 --> 00:11:20.720 Yeah, but it's usually impractical. If your variable is type object, 230 00:11:20.759 --> 00:11:23.159 you can only call methods defined in the object class itself, 231 00:11:23.200 --> 00:11:25.000 like equals hash code. 232 00:11:24.799 --> 00:11:27.639 To string, you lose access to all the specific methods 233 00:11:27.679 --> 00:11:28.679 of the actual object. 234 00:11:29.000 --> 00:11:31.919 Precisely, you'd have to cast it back to its real 235 00:11:31.960 --> 00:11:34.720 type to do anything useful, which can lead to class 236 00:11:34.759 --> 00:11:39.559 gass exceptions if you're not careful. So, while technically correct, 237 00:11:40.000 --> 00:11:43.399 referring to everything as object severely limits what you can 238 00:11:43.440 --> 00:11:45.399 do and often isn't good design. 239 00:11:45.639 --> 00:11:48.879 A good warning before we move to concurrency. Quick hits 240 00:11:49.240 --> 00:11:53.200 wrapper classes and immutability wrapper classes. 241 00:11:52.759 --> 00:11:57.519 Super concept object versions of primitives. It becomes integer, boolean 242 00:11:57.559 --> 00:12:01.039 becomes boolean, et cetera. Main uses are in collections like 243 00:12:01.080 --> 00:12:04.240 a ray list, which can only store objects, not primitives, 244 00:12:04.600 --> 00:12:05.960 and for parsing strings to. 245 00:12:05.879 --> 00:12:09.000 Primitive types and the auto boxing boxing. 246 00:12:08.720 --> 00:12:12.759 Just syntactic sugar. The compiler automatically converts between primitives and 247 00:12:12.799 --> 00:12:16.879 rappers when needed. Like adding two inteture objects under the hood, 248 00:12:16.919 --> 00:12:19.480 it's unboxing them to ends, doing the math, and maybe 249 00:12:19.480 --> 00:12:20.519 boxing the result back. 250 00:12:20.639 --> 00:12:24.480 Convenient and immutable objects like string, why are they important? 251 00:12:24.639 --> 00:12:28.039 Immutability meaning the object state can't be changed after it's created, 252 00:12:28.120 --> 00:12:32.000 is super important for a couple of reasons, primarily thread safety. 253 00:12:32.559 --> 00:12:35.240 If an object can't change, it can be shared safely 254 00:12:35.279 --> 00:12:39.200 between multiple threads without any need for synchronization, no race 255 00:12:39.240 --> 00:12:41.120 conditions possible on its state. Ah. 256 00:12:41.279 --> 00:12:43.559 That simplifies concurrent programming. 257 00:12:43.240 --> 00:12:48.200 Massively and predictability. You know that once created, its value 258 00:12:48.279 --> 00:12:52.080 won't unexpectedly change somewhere else in the code. String is 259 00:12:52.120 --> 00:12:56.200 the classic example. All string operations create new string objects. 260 00:12:56.320 --> 00:13:00.279 Okay, that's a perfect lead in to concurrency itself. Managing 261 00:13:00.360 --> 00:13:05.240 multiple threads doing things at once foundational concept multi threading, Right. 262 00:13:05.279 --> 00:13:08.919 It's about having multiple threads of execution running seemingly simultaneously 263 00:13:08.960 --> 00:13:12.720 within one program one process, and the main benefit performance 264 00:13:12.759 --> 00:13:16.519 and responsiveness. Threads are lighter than full processes share memory, 265 00:13:16.679 --> 00:13:19.080 so you can break tasks down, run them in parallel, 266 00:13:19.279 --> 00:13:22.799 utilize multiple CPU cores, and keep the application responsive, especially 267 00:13:22.840 --> 00:13:23.320 the UI. 268 00:13:23.399 --> 00:13:27.960 Gotcha, Now a really critical interview question, Wait versus sleep? 269 00:13:27.960 --> 00:13:30.320 They found similar, but they're fundamentally different. 270 00:13:30.120 --> 00:13:33.000 Right, absolute fundamental difference. This trips up so many people. 271 00:13:33.039 --> 00:13:33.480 What is it? 272 00:13:33.720 --> 00:13:36.399 The key is the lock. When a thread is inside 273 00:13:36.399 --> 00:13:39.480 a synchronized block or method, it holds a monitor lock. 274 00:13:39.960 --> 00:13:42.879 If that thread calls weight, which is a method on 275 00:13:42.919 --> 00:13:45.440 the object class, it releases the lock and goes into 276 00:13:45.480 --> 00:13:49.000 a waiting state. This allows another thread to acquire the 277 00:13:49.039 --> 00:13:52.480 lock and enter the synchronized section, maybe change the condition 278 00:13:52.519 --> 00:13:53.759 the first thread was waiting for. 279 00:13:54.360 --> 00:13:56.600 So wait, let's others in what about sleep? 280 00:13:56.919 --> 00:13:59.440 Sleep, which is a static method on the thread class, 281 00:13:59.759 --> 00:14:03.440 does not release the lock. The thread just pauses execution 282 00:14:03.480 --> 00:14:06.399 for a specified time, but it continues to hold on 283 00:14:06.440 --> 00:14:07.320 to any locks. 284 00:14:07.039 --> 00:14:10.200 It acquired, so it blocks others while it naps. 285 00:14:10.399 --> 00:14:14.600 Exactly, Wait is for interthread communication and coordination based on conditions. 286 00:14:15.320 --> 00:14:20.360 Sleep is just pausing execution. Huge difference in concurrent design. 287 00:14:20.159 --> 00:14:23.320 That's crystal clear. So wait relies on synchronization. What's the 288 00:14:23.320 --> 00:14:25.480 core idea behind synchronization itself. 289 00:14:25.600 --> 00:14:29.440 It's all about controlling access to shared resources data objects 290 00:14:29.480 --> 00:14:31.799 when multiple thread might try to modify them at the same. 291 00:14:31.600 --> 00:14:33.240 Time, preventing chaos. 292 00:14:32.879 --> 00:14:38.240 Pretty much, preventing race conditions, ensuring data consistency. Using the 293 00:14:38.240 --> 00:14:41.000 synchronized keyword on a method or a block of code 294 00:14:41.360 --> 00:14:44.320 ensures that only one thread can execute that critical section 295 00:14:44.360 --> 00:14:47.240 at any given time. It enforces mutual exclusion. 296 00:14:47.320 --> 00:14:50.360 But if you're not careful with locks, you can get 297 00:14:50.360 --> 00:14:51.000 into trouble. 298 00:14:51.279 --> 00:14:54.639 Deadlock the dreaded deadlock. Yeah, it's when two or more 299 00:14:54.720 --> 00:14:57.279 threads are stuck waiting for each other indefinitely. 300 00:14:57.440 --> 00:14:58.440 How does that happen? 301 00:14:58.639 --> 00:15:01.879 Typically, thread A holds lock one and is waiting for 302 00:15:01.919 --> 00:15:05.240 lock two, while thread B holds lock two and is 303 00:15:05.279 --> 00:15:08.639 waiting for lock one. Neither can proceed. It's a standstill. 304 00:15:08.679 --> 00:15:11.279 How do you deal with that? Detection avoidance. 305 00:15:11.679 --> 00:15:14.120 You can detect them using thread dumps, which show the 306 00:15:14.159 --> 00:15:16.480 state of all threads and the locks they hold, but 307 00:15:16.559 --> 00:15:17.639 avoidance is much better. 308 00:15:17.759 --> 00:15:18.480 Strategies. 309 00:15:18.679 --> 00:15:22.559 The guide suggests things like avoid acquiring multiple locks if possible, 310 00:15:22.679 --> 00:15:25.399 nested locks if you must, always acquire them in the 311 00:15:25.440 --> 00:15:29.759 same global order. Don't hold locks longer than necessary. Consider 312 00:15:29.840 --> 00:15:32.440 using thread dot join to wait for another thread without 313 00:15:32.480 --> 00:15:33.840 holding inappropriate locks. 314 00:15:34.200 --> 00:15:38.200 Careful design is key beyond synchronized. What about volatile and 315 00:15:38.279 --> 00:15:41.120 thread local for thread safety two different tools. 316 00:15:42.080 --> 00:15:46.440 Volatile primarily addresses visibility. It guarantees that rights to a 317 00:15:46.519 --> 00:15:50.080 volatle variable by one thread are immediately visible to other threads. 318 00:15:50.519 --> 00:15:53.519 It prevents problems with cached variable values in different CPU 319 00:15:53.639 --> 00:15:57.000 core so everyone sees the latest value right. Thread local 320 00:15:57.000 --> 00:16:01.639 tackles concurrency differently. It eliminates sharing. It provides each thread 321 00:16:01.639 --> 00:16:03.960 with its own independent copy of a variable. 322 00:16:04.080 --> 00:16:05.960 No sharing, no conflict exactly. 323 00:16:06.039 --> 00:16:08.519 Since each thread has its own instance, there's no need 324 00:16:08.559 --> 00:16:12.120 for synchronization to access it. Great for things like user 325 00:16:12.159 --> 00:16:17.360 sessions or transaction contexts, improving scalability by avoiding synchronization bottlenecks. 326 00:16:17.360 --> 00:16:20.440 Okay, that covers classic and currency. Let's jump to more 327 00:16:20.440 --> 00:16:24.799 modern Java eight onwards. Big changes with functional programming and 328 00:16:24.840 --> 00:16:26.840 the stream API. Why that shift? 329 00:16:27.120 --> 00:16:29.759 It was really driven by the need for better ways 330 00:16:29.799 --> 00:16:34.039 to handle collections and data processing, especially with multiicore processors 331 00:16:34.080 --> 00:16:34.919 becoming standard. 332 00:16:35.240 --> 00:16:37.360 Moving away from traditional loops YEA. 333 00:16:37.320 --> 00:16:41.039 And moving away from verbose imperative loops. The how to 334 00:16:41.120 --> 00:16:45.399 a more declarative style? The what functional programming concepts like 335 00:16:45.440 --> 00:16:50.279 immutability and avoiding side effects may parallel processing easier and 336 00:16:50.440 --> 00:16:54.120 code often more concise and readable. It addressed the vertical 337 00:16:54.159 --> 00:16:56.759 problem of deeply nested anonymous inner. 338 00:16:56.559 --> 00:16:59.320 Classes too, and the stream API is the main tool 339 00:16:59.360 --> 00:16:59.639 for this. 340 00:16:59.840 --> 00:17:04.119 It's the cornerstone. Yeah. Streams provide a fluent, pipeline based 341 00:17:04.119 --> 00:17:06.200 way to process sequences of elements. 342 00:17:06.640 --> 00:17:08.799 What are the advantages? Why use streams? 343 00:17:09.240 --> 00:17:14.119 Several reasons. Functional style makes aggregate operations like some average 344 00:17:14.160 --> 00:17:17.960 collect very clean, can lead to faster processing, especially with 345 00:17:18.039 --> 00:17:21.119 parallel streams which leverage multi threading automatically. 346 00:17:21.319 --> 00:17:25.000 You mentioned intermediate internal operations. How do they work and 347 00:17:25.079 --> 00:17:27.240 this idea of laziness. 348 00:17:26.839 --> 00:17:31.079 Right, stream operations are chained together. Intermediate operations like filter, map, 349 00:17:31.200 --> 00:17:35.160 distinct limit are lazy, meaning they don't actually do anything 350 00:17:35.160 --> 00:17:36.839 when you call them. They just set up the step 351 00:17:36.839 --> 00:17:39.400 in the processing pipeline. They return a new stream. 352 00:17:39.440 --> 00:17:40.440 Okay, so nothing happens. 353 00:17:40.519 --> 00:17:44.720 Yet, nothing happens until a terminal operation is called. That's 354 00:17:44.799 --> 00:17:49.279 things like four each collect min max reduce fine. First. 355 00:17:49.960 --> 00:17:53.559 Internal operations kick off the processing the pipeline and consume 356 00:17:53.599 --> 00:17:56.359 the stream. They produce a result or a side. 357 00:17:56.160 --> 00:17:59.960 Effect, and the laziness part is the efficiency game exactly. 358 00:18:00.279 --> 00:18:03.680 This is key because processing only starts at the terminal operation, 359 00:18:04.200 --> 00:18:07.119 the stream can optimize. If you have a stream pipeline 360 00:18:07.240 --> 00:18:10.519 like filter dot map dot find first, it won't necessarily 361 00:18:10.519 --> 00:18:13.880 filter and map the entire collection. It will process elements 362 00:18:13.920 --> 00:18:16.960 one by one through the pipeline just until it finds 363 00:18:16.960 --> 00:18:19.920 the first element that satisfies the filter. Then it stops. 364 00:18:20.400 --> 00:18:23.480 Huge performance benefit for large data sets or certain operations. 365 00:18:23.599 --> 00:18:28.160 That's clever. Another common stream distinction map versus flatMap. What's 366 00:18:28.160 --> 00:18:28.920 the difference is for. 367 00:18:28.839 --> 00:18:31.279 A one to one transformation. You apply a function to 368 00:18:31.319 --> 00:18:33.759 each element and you get one result element back for 369 00:18:33.799 --> 00:18:36.640 each input element. Like converting a list string to a 370 00:18:36.680 --> 00:18:39.359 list syeneger containing the links of the strings one string 371 00:18:39.400 --> 00:18:40.400 in one itager. 372 00:18:40.119 --> 00:18:42.160 Out straightforward transformation right. 373 00:18:42.279 --> 00:18:46.039 flatMap is different. It's used when your mapping function returns 374 00:18:46.039 --> 00:18:48.519 the stream for each element and you want to flatten 375 00:18:48.559 --> 00:18:51.680 all those resulting streams into a single combined stream. 376 00:18:51.799 --> 00:18:52.279 Example. 377 00:18:52.640 --> 00:18:55.759 Imagine you have a listless integer a list of lists. 378 00:18:56.119 --> 00:18:58.160 If you just map it, you'd get a streamless senature. 379 00:18:58.599 --> 00:19:00.839 But if you flat map it using a function that 380 00:19:00.920 --> 00:19:05.200 just returns the inter list as a stream list dot stream, 381 00:19:05.640 --> 00:19:08.119 you end up with a single stream nager containing all 382 00:19:08.160 --> 00:19:11.559 the integers from all the inter lists. It flattens the structure. 383 00:19:11.680 --> 00:19:15.039 Okay, flattened streams of streams got it and parallel streams 384 00:19:15.279 --> 00:19:17.160 leveraging multiple cores YEP, which. 385 00:19:17.039 --> 00:19:19.440 Is called dot parallel stream instead of dot stream or 386 00:19:19.720 --> 00:19:23.799 parallel on an existing stream. Java handles splitting the work 387 00:19:23.839 --> 00:19:26.640 across multiple threads using the common fork joint pool. 388 00:19:26.759 --> 00:19:27.640 But there's a catch. 389 00:19:27.720 --> 00:19:29.759 The main catch is that the order of elements is 390 00:19:29.799 --> 00:19:33.759 not guaranteed during parallel processing because different threads might finish 391 00:19:33.759 --> 00:19:36.799 processing different chunks out of order, so if the dequence matters, 392 00:19:36.960 --> 00:19:39.559 parallel streams might not be suitable, or you need to 393 00:19:39.559 --> 00:19:41.119 handle ordering carefully afterwards. 394 00:19:41.240 --> 00:19:45.240 Get to know. Finally, for modern Java features, the optional 395 00:19:45.279 --> 00:19:47.319 class introduced to fight. 396 00:19:47.440 --> 00:19:49.480 The dreaded null pointer exception. 397 00:19:49.240 --> 00:19:50.519 The billion dollar mistake. 398 00:19:50.640 --> 00:19:54.039 Indeed, optional is basically a container object that may or 399 00:19:54.079 --> 00:19:55.799 may not contain a non null value. 400 00:19:55.920 --> 00:19:58.640 So it's like a box that might be empty exactly. 401 00:19:59.039 --> 00:20:01.400