Friday, November 28, 2025

Interview Question : Implement Custom HashMap

Below is the best Java interview-level explanation + full custom HashMap implementation written in clean, production-style code.

I will give you:

  1. Concept explanation (what interviewer expects)

  2. Key points to mention verbally

  3. Full working implementation of CustomHashMap<K, V>

  4. Example usage


✅ 1. Concept Interviewers Expect

A custom HashMap usually demonstrates:

  • Array of buckets

  • Each bucket stores linked list (or tree – but interview usually accepts list)

  • put(key, value)

  • get(key)

  • remove(key) (optional but good)

  • Handling hash collision

  • Handling resize / rehash

You do NOT need to implement TreeNodes like JDK HashMap unless asked.


✅ 2. Key points to say in an interview

If asked verbally:

“My custom HashMap uses an array of buckets.
Each bucket holds a linked list of entries.
Key is converted to index by (hash & (capacity - 1)).
Collision is handled using chaining.
When load factor exceeds threshold, I resize the array and rehash all entries.”

This is enough to pass.


✅ 3. Full Implementation — CustomHashMap<K, V>

✔ Clean

✔ Easy to explain

✔ Close to how JDK HashMap works

public class CustomHashMap<K, V> {

    // Node inside each bucket (LinkedList)
    static class Entry<K, V> {
        K key;
        V value;
        Entry<K, V> next;

        Entry(K key, V value, Entry<K, V> next) {
            this.key = key;
            this.value = value;
            this.next = next;
        }
    }

    private Entry<K, V>[] table;      // bucket array
    private int capacity = 16;        // default size
    private float loadFactor = 0.75f;
    private int size = 0;             // current number of entries

    public CustomHashMap() {
        table = new Entry[capacity];
    }

    private int hash(K key) {
        return key == null ? 0 : (key.hashCode() & (capacity - 1));
    }

    public void put(K key, V value) {
        int index = hash(key);
        Entry<K, V> head = table[index];

        // Check if key already exists -> update it
        Entry<K, V> curr = head;
        while (curr != null) {
            if ((key == null && curr.key == null) || (key != null && key.equals(curr.key))) {
                curr.value = value;  // update
                return;
            }
            curr = curr.next;
        }

        // Insert new entry at the head of list
        Entry<K, V> newEntry = new Entry<>(key, value, head);
        table[index] = newEntry;
        size++;

        // Resize check
        if ((1.0 * size) / capacity >= loadFactor) {
            resize();
        }
    }

    public V get(K key) {
        int index = hash(key);
        Entry<K, V> curr = table[index];

        while (curr != null) {
            if ((key == null && curr.key == null) || (key != null && key.equals(curr.key))) {
                return curr.value;
            }
            curr = curr.next;
        }

        return null; // not found
    }

    public V remove(K key) {
        int index = hash(key);
        Entry<K, V> curr = table[index];
        Entry<K, V> prev = null;

        while (curr != null) {
            if ((key == null && curr.key == null) || (key != null && key.equals(curr.key))) {

                // delete node
                if (prev == null) {
                    table[index] = curr.next;
                } else {
                    prev.next = curr.next;
                }

                size--;
                return curr.value;
            }

            prev = curr;
            curr = curr.next;
        }
        return null;
    }

    // Resize: Double capacity and rehash all entries
    private void resize() {
        int oldCapacity = capacity;
        capacity = capacity * 2;

        Entry<K, V>[] oldTable = table;
        table = new Entry[capacity];
        size = 0;

        for (int i = 0; i < oldCapacity; i++) {
            Entry<K, V> entry = oldTable[i];
            while (entry != null) {
                put(entry.key, entry.value); // rehash
                entry = entry.next;
            }
        }
    }

    public int size() {
        return size;
    }
}

✅ 4. Example Usage

public class Main {
    public static void main(String[] args) {
        CustomHashMap<String, Integer> map = new CustomHashMap<>();

        map.put("A", 1);
        map.put("B", 2);
        map.put("C", 3);

        System.out.println(map.get("B")); // 2

        map.put("B", 20); 
        System.out.println(map.get("B")); // 20

        map.remove("A");

        System.out.println(map.size()); // 2
    }
}

Want an even more advanced version?

I can also give you:

  • Open addressing (linear probing) HashMap

  • HashMap with TreeBins like JDK8

  • ConcurrentHashMap simplified version

  • Memory-efficient hash map with primitive arrays (Agrona-style)

Tell me which version you'd want next.

Wednesday, November 26, 2025

wait & notify

 Why wait() & notify() has to be from synchronized method

When a thread invokes d.wait, it must own the intrinsic lock for d — otherwise an error is thrown. Invoking wait inside a synchronized method is a simple way to acquire the intrinsic lock.

When wait is invoked, the thread releases the lock and suspends execution. At some future time, another thread will acquire the same lock and invoke Object.notifyAll, informing all threads waiting on that lock that something important has happened:



Guarded Blocks

Threads often have to coordinate their actions. The most common coordination idiom is the guarded block. Such a block begins by polling a condition that must be true before the block can proceed. There are a number of steps to follow in order to do this correctly.

Suppose, for example guardedJoy is a method that must not proceed until a shared variable joy has been set by another thread. Such a method could, in theory, simply loop until the condition is satisfied, but that loop is wasteful, since it executes continuously while waiting.

public void guardedJoy() {
    // Simple loop guard. Wastes
    // processor time. Don't do this!
    while(!joy) {}
    System.out.println("Joy has been achieved!");
}

A more efficient guard invokes Object.wait to suspend the current thread. The invocation of wait does not return until another thread has issued a notification that some special event may have occurred — though not necessarily the event this thread is waiting for:

public synchronized void guardedJoy() {
    // This guard only loops once for each special event, which may not
    // be the event we're waiting for.
    while(!joy) {
        try {
            wait();
        } catch (InterruptedException e) {}
    }
    System.out.println("Joy and efficiency have been achieved!");
}

Note: Always invoke wait inside a loop that tests for the condition being waited for. Don't assume that the interrupt was for the particular condition you were waiting for, or that the condition is still true.

Like many methods that suspend execution, wait can throw InterruptedException. In this example, we can just ignore that exception — we only care about the value of joy.

Why is this version of guardedJoy synchronized? Suppose d is the object we're using to invoke wait. When a thread invokes d.wait, it must own the intrinsic lock for d — otherwise an error is thrown. Invoking wait inside a synchronized method is a simple way to acquire the intrinsic lock.

When wait is invoked, the thread releases the lock and suspends execution. At some future time, another thread will acquire the same lock and invoke Object.notifyAll, informing all threads waiting on that lock that something important has happened:

public synchronized notifyJoy() {
    joy = true;
    notifyAll();
}

Some time after the second thread has released the lock, the first thread reacquires the lock and resumes by returning from the invocation of wait.


Note: There is a second notification method, notify, which wakes up a single thread. Because notify doesn't allow you to specify the thread that is woken up, it is useful only in massively parallel applications — that is, programs with a large number of threads, all doing similar chores. In such an application, you don't care which thread gets woken up.

Let's use guarded blocks to create a Producer-Consumer application. This kind of application shares data between two threads: the producer, that creates the data, and the consumer, that does something with it. The two threads communicate using a shared object. Coordination is essential: the consumer thread must not attempt to retrieve the data before the producer thread has delivered it, and the producer thread must not attempt to deliver new data if the consumer hasn't retrieved the old data.

In this example, the data is a series of text messages, which are shared through an object of type Drop:

public class Drop {
    // Message sent from producer
    // to consumer.
    private String message;
    // True if consumer should wait
    // for producer to send message,
    // false if producer should wait for
    // consumer to retrieve message.
    private boolean empty = true;

    public synchronized String take() {
        // Wait until message is
        // available.
        while (empty) {
            try {
                wait();
            } catch (InterruptedException e) {}
        }
        // Toggle status.
        empty = true;
        // Notify producer that
        // status has changed.
        notifyAll();
        return message;
    }

    public synchronized void put(String message) {
        // Wait until message has
        // been retrieved.
        while (!empty) {
            try { 
                wait();
            } catch (InterruptedException e) {}
        }
        // Toggle status.
        empty = false;
        // Store message.
        this.message = message;
        // Notify consumer that status
        // has changed.
        notifyAll();
    }
}

The producer thread, defined in Producer, sends a series of familiar messages. The string "DONE" indicates that all messages have been sent. To simulate the unpredictable nature of real-world applications, the producer thread pauses for random intervals between messages.

import java.util.Random;

public class Producer implements Runnable {
    private Drop drop;

    public Producer(Drop drop) {
        this.drop = drop;
    }

    public void run() {
        String importantInfo[] = {
            "Mares eat oats",
            "Does eat oats",
            "Little lambs eat ivy",
            "A kid will eat ivy too"
        };
        Random random = new Random();

        for (int i = 0;
             i < importantInfo.length;
             i++) {
            drop.put(importantInfo[i]);
            try {
                Thread.sleep(random.nextInt(5000));
            } catch (InterruptedException e) {}
        }
        drop.put("DONE");
    }
}

The consumer thread, defined in Consumer, simply retrieves the messages and prints them out, until it retrieves the "DONE" string. This thread also pauses for random intervals.

import java.util.Random;

public class Consumer implements Runnable {
    private Drop drop;

    public Consumer(Drop drop) {
        this.drop = drop;
    }

    public void run() {
        Random random = new Random();
        for (String message = drop.take();
             ! message.equals("DONE");
             message = drop.take()) {
            System.out.format("MESSAGE RECEIVED: %s%n", message);
            try {
                Thread.sleep(random.nextInt(5000));
            } catch (InterruptedException e) {}
        }
    }
}

Finally, here is the main thread, defined in ProducerConsumerExample, that launches the producer and consumer threads.

public class ProducerConsumerExample {
    public static void main(String[] args) {
        Drop drop = new Drop();
        (new Thread(new Producer(drop))).start();
        (new Thread(new Consumer(drop))).start();
    }
}

Note: The Drop class was written in order to demonstrate guarded blocks. To avoid re-inventing the wheel, examine the existing data structures in the Java Collections Framework before trying to code your own data-sharing objects. For more information, refer to the Questions and Exercises section.

CompletableFuture

  Welcome back to  our concurrency series ! In our first discussion, we likely touched on the traditional models of threading. Today, we’re ...