#Post3 In our previous posts, we explored: • How HashMap works internally: https://lnkd.in/db--5_JJ • Why HashMap is not thread safe: https://lnkd.in/d6dAMf8q Now let’s understand something more important 👇 How does ConcurrentHashMap achieve thread safety? At a high level, ConcurrentHashMap is designed to provide: • Thread safety • High performance • Better concurrency But how does it actually do that? Instead of locking the entire map, ConcurrentHashMap uses a combination of techniques: 1. CAS (Compare-And-Swap) Before applying any lock, ConcurrentHashMap first tries to update the value using CAS. → Update the value only if it has not been changed by another thread If successful → no locking required If failed → retry or use locking This reduces unnecessary locking and improves performance. We will learn more about CAS in future posts, but for now think of CAS as an atomic operation (either it succeeds or nothing changes). 2. Bucket-Level Locking If the operation cannot be completed using CAS, then locking is applied. Unlike synchronized HashMap (which locks the whole map), ConcurrentHashMap locks only a specific bucket (or node) when required. Example: • Thread-1 → working on bucket 2 • Thread-2 → working on bucket 5 Both can proceed in parallel without blocking each other. Working of get() and put() in ConcurrentHashMap 1. Lock-Free Reads (get) One of the most important optimizations: Reads do NOT require locking. ConcurrentHashMap uses volatile variables to ensure visibility across threads. This makes read operations extremely fast. We will explore the volatile keyword in upcoming posts. 2. How put() Works (Simplified) When inserting a value: • Calculate hash • Find bucket index Then: → If bucket is empty → insert using CAS (no lock) (Do not consider CAS will be successful only when bucket is empty/null) → If bucket is not empty → lock that bucket and update This approach ensures: • Minimum locking • High throughput • Better scalability Key takeaway ConcurrentHashMap achieves thread safety by: • Using CAS to avoid unnecessary locks • Locking only specific buckets instead of the whole map • Allowing lock-free read operations This is why it performs much better than synchronized maps in multi-threaded environments. In the next post, we’ll explore: • CAS (Compare-And-Swap) in detail • Volatile keyword Verdict : In our further posts we will shift our attention towards working of Thread in Java, so that concepts like CAS, volatile, and many more sounds familiar. #Java #SoftwareEngineering #BackendDevelopment #Multithreading #ConcurrentProgramming #Programming
#Post2 In my previous post, we explored how HashMap works internally. (If you haven't read it yet, you can find it here: https://lnkd.in/dnwPP-iv) One important point mentioned there was: HashMap is not thread safe. But what does that actually mean? Let’s understand it with an example 👇 Imagine two threads trying to update the same HashMap at the same time. Example: → map.put("Apple", 10); → map.put("Banana", 20); Since HashMap is not synchronized, both threads may try to modify the internal bucket structure at the same time. This can cause problems like: • Data inconsistency • Lost updates Why does this happen? Because operations like put() and resize() involve multiple internal steps. If two threads interleave during these steps, the internal structure can become corrupted. Example scenario: • Thread-1 is inserting an entry • Thread-2 is resizing the HashMap Both modify the bucket array concurrently → leading to unpredictable results. So how do we solve this problem? One option is to synchronize access to the HashMap. This can be done using a synchronized block or by using Collections.synchronizedMap(). However, these approaches lock the entire map, which reduces concurrency when multiple threads try to access it. Java therefore provides a better alternative: ConcurrentHashMap Instead of locking the entire map, ConcurrentHashMap uses finer-grained locking and internal concurrency mechanisms, allowing multiple threads to safely access the map. This allows: • High concurrency • Better performance compared to synchronized maps • Thread-safe read and write operations Example usage → ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>(); → map.put("Apple", 10); Multiple threads can safely read and write without corrupting the data structure. Key takeaway • Use HashMap when working in a single-threaded environment • Use ConcurrentHashMap when multiple threads need concurrent read/write In the next post, we’ll explore how ConcurrentHashMap works internally and how it achieves thread safety. #Java #SoftwareEngineering #BackendDevelopment #Multithreading #Programming #ConcurrentProgramming
One interesting detail: get() in ConcurrentHashMap is completely lock-free