How HashMap Works in Java

Day 12 Today’s Java practice was about solving the Leader Element problem. Instead of using nested loops, I used a single traversal from right to left, which made the solution clean and efficient. A leader element is one that is greater than all the elements to its right. Example: Input: {16,17,5,3,4,2} Leaders: 17, 5, 4, 2 🧠 Approach I used: ->Start traversing from the rightmost element ->Keep track of the maximum element seen so far ->If the current element is greater than the maximum, it becomes a leader ->This is an efficient approach with O(n) time complexity and no extra space. ================================================= // Online Java Compiler // Use this editor to write, compile and run your Java code online class Main {   public static void main(String[] args) {     int a [] ={16,17,5,3,4,2};     int length=a.length;     int maxRight=a[length-1];     System.out.print("Leader elements are :"+maxRight+" ");           for(int i=a[length-2];i>=0;i--)     {       if(a[i]>maxRight)       {         maxRight=a[i];         System.out.print(maxRight+" ");       }     }   } } Output:Leader elements are :2 4 5 17  #AutomationTestEngineer #Selenium #Java #DeveloperJourney #Arrays

“Java is too hard to write.” Every developer at some point. But are we talking about Java then or Java now? Old Java: You had to write a lot to do something small. Modern Java: Here I did it fast. You’re welcome. The truth is. Java has changed a lot. It has streams, records and more… it’s not the same language people like to complain about. And here’s something cool. I found a site that shows new Java code side, by side: https://lnkd.in/g7n9VhMD (https://lnkd.in/g7n9VhMD) It’s like watching Java go through a glow-up. So next time someone says "Java is too hard to write" Just ask them: Which Java are you talking about? Java didn’t stay hard to write. We just didn’t keep up with Java. #Java #JDK #Features #Software #Engineering

Most Java developers write multithreaded code every day. But most of us don't know what happens inside the JVM when two threads hit the same counter — and things get quiet. I've been preparing deeply for senior Java interviews and decided to document everything I learned about multithreading from scratch. Not just definitions — real internals. Here's what Module 02 covers: 🔹 Multithreading 🔹 Process vs. Program vs. Thread 🔹 Thread lifecycle (all 6 states — and why there's no RUNNING state) 🔹 Race conditions — why count++ is never safe 🔹 synchronized — object lock vs class lock (most devs miss this) 🔹 ReentrantLock — tryLock, fairness, reentrancy explained 🔹 ReadWriteLock — when to separate reads from writes 🔹 Deadlock, Livelock, Starvation — all three with code and fixes 🔹 wait() / notify() — the producer-consumer pattern the right way 🔹 volatile vs Atomic — visibility vs atomicity (not the same thing) 🔹 ABA problem — why CAS isn't always enough 🔹 ExecutorService + ThreadPoolExecutor internals 🔹 Callable, Future — handling results and exceptions from threads 🔹 CompletableFuture — full methods guide (thenApply, thenCombine, exceptionally…) 🔹 ThreadLocal — usage, and the memory leak trap in thread pools This is Part 03 of my Java Interview Prep series. Part 01 covered JVM Internals, and Part 02 covered OOPs Internals - Find the post link in the comments.  More modules on Collections, Streams, Spring Boot, etc., are coming. If you're preparing for a senior Java role or want to understand what's really happening when your threads collide, finally, this is for you. #Java #Multithreading #JavaConcurrency #InterviewPrep #CoreJava #BackendDevelopment #JavaDeveloper #LearningInPublic

Same result. Half the code. Most Java developers don’t use this 😱 Java Fundamentals Series | Part 21 Can you spot the improvement? 👇 List<String> names = Arrays.asList( "Alice", "Bob", "Charlie" ); // ❌ Verbose Lambda names.forEach(name -> System.out.println(name)); // ✅ Method Reference names.forEach(System.out::println); Cleaner. More readable. More professional. 💪 4 Types of Method References 👇 // 1. Static method Function<Integer, Integer> abs = Math::abs; // 2. Instance method of object Function<String, String> upper = String::toUpperCase; // 3. Instance method of instance String prefix = "DBS: "; Function<String, String> addPrefix = prefix::concat; // 4. Constructor reference Function<String, StringBuilder> builder = StringBuilder::new; Real-world example 👇 // ❌ Lambda transactions.stream() .map(t -> t.getAmount()) .forEach(a -> System.out.println(a)); // ✅ Method Reference transactions.stream() .map(Transaction::getAmount) .forEach(System.out::println); Summary: 🔴 Writing lambdas everywhere 🟢 Use method references when method already exists 🤯 Cleaner code = fewer lines + better readability ⸻ 👉 Posting more real-world fixes like this. Have you used method references? Drop a :: below 👇 #Java #JavaFundamentals #BackendDevelopment #LearningInPublic #SDE2

🚀 Java Puzzle: Why this prints "100" even after using "final"? 🤯 Looks like a bug… but it’s actually Java behavior 👇 👉 Example: final int[] arr = {1, 2, 3}; arr[0] = 100; System.out.println(arr[0]); // 100 😮 👉 Wait… "final" but still changing? 🤔 💡 Reality of "final": - "final" → reference cannot change - NOT → object data cannot change 👉 So: - ❌ "arr = new int[]{4,5,6}" → not allowed - ✅ "arr[0] = 100" → allowed --- 🔥 Now the REAL twist 😳 final StringBuilder sb = new StringBuilder("Java"); sb.append(" Developer"); System.out.println(sb); // Java Developer 😮 👉 Again changing despite "final" 🔥 Golden Rule: 👉 "final" means: - You cannot point to a new object - But you CAN modify the existing object 💡 Common misconception: 👉 Many think "final = constant" (NOT always true) 💬 Did you also think "final" makes everything immutable? #Java #JavaDeveloper #Programming #Coding #100DaysOfCode #TechTips #JavaTips #InterviewPrep #Developers #SoftwareEngineering

Most Java developers use int and Integer without thinking twice. But these two are not the same thing, and not knowing the difference can cause real bugs in your code. Primitive types like string, int, double, and boolean are simple and fast. They store values directly in memory and cannot be null. Wrapper classes like Integer, Double, and Boolean are full objects. They can be null, they work inside collections like lists and maps, and they come with useful built-in methods. The four key differences every Java developer should know are nullability, collection support, utility methods, and performance. Primitives win on speed and memory. Wrapper classes win on flexibility. Java also does something called autoboxing and unboxing. Autoboxing is when Java automatically converts a primitive into its wrapper class. Unboxing is the opposite, converting a wrapper class back into a primitive. This sounds helpful, and most of the time it is. But when a wrapper class is null and Java tries to unbox it, your program will crash with a NullPointerException. This is one of the most common and confusing bugs that Java beginners and even experienced developers run into. The golden rule is simple. Use primitives by default. Switch to wrapper classes only when you need null support, collections, or utility methods. I wrote a full breakdown covering all of this in detail, with examples. https://lnkd.in/gnX6ZEMw #Java #JavaDeveloper #Programming #SoftwareDevelopment #Backend #CodingTips #CleanCode #100DaysOfCode

💡 Java Collections (Revision)— What to Use, When, and What's Happening Internally Most developers use collections daily. Very few understand what's happening under the hood. Here's a clean breakdown 👇 🔹 LIST — Ordered, Allows Duplicates ArrayList ✔ Backed by dynamic array ✔ Fast random access O(1) ✔ Use when: frequent reads, less modification LinkedList ✔ Doubly linked list ✔ Fast insert/delete O(1) ✔ Use when: frequent insertions/deletions 🔹 SET — Unique Elements HashSet ✔ Uses HashMap internally ✔ No order, O(1) operations ✔ Use when: fast lookup, uniqueness LinkedHashSet ✔ HashSet + insertion order ✔ Uses LinkedHashMap internally ✔ Use when: need order + uniqueness TreeSet ✔ Red-Black Tree, sorted order, O(log n) ✔ Use when: sorted data required 🔹 MAP — Key-Value Pairs HashMap ✔ Bucket array + hashing ✔ Linked list → Tree (Java 8+), O(1) avg ✔ Use when: fast key-value access LinkedHashMap ✔ HashMap + doubly linked list ✔ Maintains insertion order ✔ Use when: LRU cache / predictable iteration TreeMap ✔ Red-Black Tree, sorted keys ✔ Use when: sorted map needed ConcurrentHashMap ✔ Thread-safe, CAS + bucket-level locking ✔ Lock-free reads ✔ Use when: multi-threaded systems 🔥 Internal Patterns You Should Know ✔ Hashing converts key to bucket index ✔ Collisions resolved via Linked List then Tree ✔ CAS enables lock-free updates in ConcurrentHashMap ✔ Red-Black Tree keeps operations at O(log n) ✔ Doubly Linked List maintains insertion order ⚠️ Common Mistakes ✔ Using LinkedList for random access ✔ Bad hashCode() causing performance issues ✔ Using HashMap in multithreaded code ✔ Ignoring ordering requirements 🧠 One Line Memory Trick l List → Order + Duplicates Set → No duplicates Map → Key → Value Mastering collections = mastering backend performance. #Java #Collections #DataStructures #SoftwareEngineering #BackendDevelopment #SystemDesign

🚀 CyclicBarrier in Java — Small Concept, Powerful Synchronization In multithreading, coordination between threads is critical ⚡ 👉 CyclicBarrier allows multiple threads to wait for each other at a common point before continuing — ensuring everything stays in sync 🔥 💡 Think of it like a checkpoint 🏁 No thread moves forward until all have arrived! 🌍 Real-Time Example Imagine a report generation system 📊 Multiple threads fetch data from different APIs 📡 Each processes its own data ⚙️ Final report should generate only when all threads finish 👉 With CyclicBarrier, you ensure: ✅ All threads complete before aggregation ✅ No partial or inconsistent data ✅ Smooth parallel execution 💻 Quick Code Example import java.util.concurrent.CyclicBarrier; public class Demo { public static void main(String[] args) { CyclicBarrier barrier = new CyclicBarrier(3, () -> System.out.println("All threads reached. Generating final report...")); Runnable task = () -> { try { System.out.println(Thread.currentThread().getName() + " fetching data..."); Thread.sleep(1000); barrier.await(); System.out.println(Thread.currentThread().getName() + " done!"); } catch (Exception e) { e.printStackTrace(); } }; for (int i = 0; i < 3; i++) new Thread(task).start(); } } 💪 Why it’s powerful ✔️ Keeps threads perfectly synchronized ✔️ Prevents incomplete execution ❌ ✔️ Reusable for multiple phases ♻️ 🔥 Final Thought 👉 It’s a small but powerful feature — use it wisely based on your project needs to ensure the right level of synchronization without overcomplicating your design. #Java #Multithreading #Concurrency #BackendDevelopment #SoftwareEngineering

🚀 If you don’t understand Java Memory… you don’t fully understand Java. Behind every Java program, memory is managed in different areas — and each has a specific role. --- 🧠 Java Memory Structure (JVM) 🔹 1. Stack Memory • Stores method calls & local variables • Each thread has its own stack • Fast access ⚡ --- 🔹 2. Heap Memory • Stores objects & instance variables • Shared across all threads • Managed by Garbage Collector --- 🔹 3. Method Area (MetaSpace) • Stores class metadata • Static variables • Method information --- 🔹 4. PC Register • Stores current executing instruction • Each thread has its own --- 🔹 5. Native Method Stack • Used for native (C/C++) methods --- 💡 Why this matters ✔ Helps in debugging memory issues ✔ Important for interviews ✔ Useful for performance optimization --- 📌 Simple Understanding Stack → Execution Heap → Objects Method Area → Class data --- 🚀 Strong JVM fundamentals = Strong Java developer --- 💬 Which part of JVM memory confuses you the most? #Java #CoreJava #JVM #Programming #SoftwareEngineering #JavaDeveloper

🚀 Day 2 – Subtle Java Behavior That Can Surprise You Today I explored the difference between "==" and ".equals()" in Java — and it’s more important than it looks. String a = "hello"; String b = "hello"; System.out.println(a == b); // true System.out.println(a.equals(b)); // true Now this: String c = new String("hello"); System.out.println(a == c); // false System.out.println(a.equals(c)); // true 👉 "==" compares reference (memory location) 👉 ".equals()" compares actual content 💡 The catch? Because of the String Pool, sometimes "==" appears to work correctly… until it doesn’t. This small misunderstanding can lead to tricky bugs, especially while working with collections or APIs. ✔ Rule I’m following: Always use ".equals()" for value comparison unless you explicitly care about references. #Java #BackendDevelopment #JavaBasics #LearningInPublic