{"title":"Monitor Object Pattern","description":null,"content":"# Monitor Object Pattern Explained\n\nYou're building a bank account system. Multiple threads need to deposit and withdraw money. The balance must never go negative and updates must be atomic.\n\nYou could expose the balance field and have each caller acquire locks before accessing it. But now every piece of code that touches an account must remember to lock correctly. Miss a lock somewhere, and you have a race condition. Forget to release it, and you have a deadlock.\n\nThe **Monitor Object Pattern** solves this by encapsulating synchronization within the object itself. The account object owns its lock and all operations automatically synchronize. Callers just call `deposit()` or `withdraw()`. They don't know or care about locks. The object guarantees thread safety internally.\n\nIn this article, we'll explore:\n\n- What is the Monitor Object Pattern?\n- The problem it solves\n- How it works\n- Implementation details\n- Condition variables and wait/notify\n- Common pitfalls\n- When to use it in LLD interviews\n\n---\n\nIf you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](undefined)\n\n---\n\n## 1. What is the Monitor Object Pattern?\n\nThe **Monitor Object Pattern** is a synchronization pattern where an object encapsulates both its data and the synchronization needed to access that data safely. All public methods that access shared state are automatically synchronized. The object acts as its own guardian.\n\n\n```mermaid\nflowchart TD\n subgraph Monitor[\"Monitor Object\"]\n L[Lock]:::orange\n D[(Private Data)]:::purple\n M1[method1]:::primary\n M2[method2]:::primary\n M3[method3]:::primary\n\n M1 --> L\n M2 --> L\n M3 --> L\n L --> D\n end\n\n T1[Thread 1]:::secondary --> M1\n T2[Thread 2]:::secondary --> M2\n T3[Thread 3]:::secondary --> M3\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\nThe key insight is that synchronization is the object's responsibility, not the caller's. Callers interact with a clean interface without worrying about concurrency.\n\n### Core Principles\n\n1. **Encapsulation:** Private data, public synchronized methods\n2. **Mutual Exclusion:** Only one thread executes inside the monitor at a time\n3. **Condition Synchronization:** Threads can wait for conditions and be notified\n\n---\n\n## 2. The Problem: External Locking is Error-Prone\n\nWithout the Monitor Object Pattern, synchronization becomes the caller's burden.\n\n### The External Locking Approach\n\n\n```mermaid\nflowchart LR\n subgraph Callers[\"Multiple Callers\"]\n C1[Caller 1]:::primary\n C2[Caller 2]:::primary\n C3[Caller 3]:::primary\n end\n\n L[Shared Lock]:::orange\n\n subgraph Object[\"Data Object\"]\n D[(balance)]:::purple\n end\n\n C1 -->|must lock| L\n C2 -->|must lock| L\n C3 -->|must lock| L\n L --> D\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\nEvery caller must:\n\n1. Know which lock protects the data\n2. Acquire the lock before access\n3. Release the lock after access\n4. Handle lock correctly in all code paths\n\n### What Goes Wrong\n\n**Problem 1: Forgotten Locks**\n\n\n```java\n// Developer A remembers to lock\nlock.acquire();\naccount.balance += 100;\nlock.release();\n\n// Developer B forgets\naccount.balance -= 50; // Race condition!\n```\n\n\n**Problem 2: Wrong Lock**\n\n\n```java\n// Different locks for the same data\nlockA.acquire();\naccount.balance += 100;\nlockA.release();\n\nlockB.acquire(); // Wrong lock!\naccount.balance -= 50;\nlockB.release();\n```\n\n\n**Problem 3: Lock Leaks**\n\n\n```java\nlock.acquire();\naccount.balance += 100;\nvalidate(account); // Throws exception!\nlock.release(); // Never reached\n```\n\n\n**Problem 4: Inconsistent Operations**\n\n\n```java\nlock.acquire();\naccount.balance += amount;\nlock.release();\n\n// Gap here - another thread can see inconsistent state\n\nlock.acquire();\naccount.lastTransaction = amount;\nlock.release();\n```\n\n\n### The Solution: Monitor Object\n\nThe monitor encapsulates synchronization. Callers never touch locks.\n\n\n```mermaid\nflowchart LR\n subgraph Callers[\"Multiple Callers\"]\n C1[Caller 1]:::primary\n C2[Caller 2]:::primary\n C3[Caller 3]:::primary\n end\n\n subgraph Monitor[\"Account Monitor\"]\n M[deposit
withdraw
getBalance]:::orange\n L[Internal Lock]:::secondary\n D[(balance)]:::purple\n\n M --> L --> D\n end\n\n C1 --> M\n C2 --> M\n C3 --> M\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\nCallers just call methods. The monitor handles all locking internally.\n\n---\n\n## 3. How the Monitor Object Works\n\nA monitor object has three components:\n\n1. **Private state** that needs protection\n2. **Synchronized methods** that access the state\n3. **An implicit lock** (one per object)\n\n### Execution Model\n\nWhen a thread calls a synchronized method:\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant T2 as Thread 2\n participant M as Monitor\n participant L as Lock\n\n T1->>M: call deposit()\n M->>L: acquire lock\n L-->>M: lock granted\n Note over M: Execute deposit()\n\n T2->>M: call withdraw()\n M->>L: acquire lock\n Note over T2,L: Blocked - lock held by T1\n\n M->>L: release lock\n L-->>M: lock released\n\n L-->>T2: lock granted\n Note over M: Execute withdraw()\n M->>L: release lock\n```\n\n\nOnly one thread executes inside the monitor at any time. Others wait at the door.\n\n### State Diagram\n\n\n```mermaid\nstateDiagram-v2\n [*] --> Unlocked: Monitor Created\n\n Unlocked --> Executing: Thread enters\n Executing --> Unlocked: Thread exits\n\n Executing --> Waiting: Thread calls wait()\n Waiting --> Executing: Thread notified\n\n note right of Executing: Only one thread here\n note right of Waiting: Can have multiple waiting threads\n```\n\n\n---\n\n## 4. Basic Implementation\n\nLet's build a thread-safe bank account using the Monitor Object Pattern.\n\n### 4.1 Simple Monitor Object\n\n\n```java\npublic class BankAccount {\n private double balance;\n\n public BankAccount(double initialBalance) {\n this.balance = initialBalance;\n }\n\n public synchronized void deposit(double amount) {\n if (amount <= 0) {\n throw new IllegalArgumentException(\"Amount must be positive\");\n }\n balance += amount;\n }\n\n public synchronized void withdraw(double amount) {\n if (amount <= 0) {\n throw new IllegalArgumentException(\"Amount must be positive\");\n }\n if (balance < amount) {\n throw new IllegalStateException(\"Insufficient funds\");\n }\n balance -= amount;\n }\n\n public synchronized double getBalance() {\n return balance;\n }\n}\n```\n\n\nThe `synchronized` keyword makes each method acquire the object's intrinsic lock before executing.\n\n### 4.2 Using the Monitor\n\n\n```java\nBankAccount account = new BankAccount(1000);\n\n// Thread 1\naccount.deposit(500);\n\n// Thread 2\naccount.withdraw(200);\n\n// Thread 3\ndouble balance = account.getBalance();\n```\n\n\nCallers don't manage locks. The account handles everything.\n\n### 4.3 Explicit Lock Version\n\nFor more control, use explicit locks instead of the `synchronized` keyword.\n\n\n```java\npublic class BankAccount {\n private final Lock lock = new ReentrantLock();\n private double balance;\n\n public void deposit(double amount) {\n lock.lock();\n try {\n balance += amount;\n } finally {\n lock.unlock();\n }\n }\n\n public void withdraw(double amount) {\n lock.lock();\n try {\n if (balance < amount) {\n throw new IllegalStateException(\"Insufficient funds\");\n }\n balance -= amount;\n } finally {\n lock.unlock();\n }\n }\n\n public double getBalance() {\n lock.lock();\n try {\n return balance;\n } finally {\n lock.unlock();\n }\n }\n}\n```\n\n\nThe `try-finally` pattern ensures the lock is always released.\n\n---\n\n## 5. Condition Variables: Wait and Notify\n\nSometimes a thread needs to wait for a condition before proceeding. The Monitor Object Pattern supports this through condition variables.\n\n### The Problem: Busy Waiting\n\n\n```java\n// Bad: busy waiting burns CPU\npublic synchronized void withdraw(double amount) {\n while (balance < amount) {\n // Spin, checking repeatedly\n }\n balance -= amount;\n}\n```\n\n\nThis wastes CPU cycles and holds the lock, preventing deposits.\n\n### The Solution: Wait and Notify\n\n\n```mermaid\nflowchart TD\n A[Thread calls withdraw]:::primary --> B{balance >= amount?}:::orange\n B -->|Yes| C[Perform withdrawal]:::green\n B -->|No| D[wait - release lock and sleep]:::secondary\n D --> E[Another thread deposits]:::primary\n E --> F[notify - wake waiting threads]:::orange\n F --> D\n D -->|Woken up| B\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Implementation with Wait/Notify\n\n\n```java\npublic class BankAccount {\n private double balance;\n\n public synchronized void deposit(double amount) {\n balance += amount;\n notifyAll(); // Wake up waiting withdrawers\n }\n\n public synchronized void withdraw(double amount) throws InterruptedException {\n while (balance < amount) {\n wait(); // Release lock and sleep\n }\n balance -= amount;\n }\n}\n```\n\n\nWhen a thread calls `wait()`:\n\n1. It releases the monitor lock\n2. It goes to sleep\n3. When notified, it reacquires the lock and continues\n\n### Why Use `while` Instead of `if`?\n\n\n```java\n// Wrong: using if\nif (balance < amount) {\n wait();\n}\nbalance -= amount; // May fail - condition might not hold!\n\n// Correct: using while\nwhile (balance < amount) {\n wait();\n}\nbalance -= amount; // Condition guaranteed to hold\n```\n\n\nSpurious wakeups can occur. The thread may wake up even when the condition isn't met. Always recheck in a loop.\n\n### Sequence Diagram\n\n\n```mermaid\nsequenceDiagram\n participant W as Withdrawer\n participant M as Monitor\n participant D as Depositor\n\n W->>M: withdraw(500)\n Note over W,M: balance = 100\n M->>M: balance < 500, wait()\n Note over W: Releases lock, sleeps\n\n D->>M: deposit(600)\n Note over M: balance = 700\n M->>M: notifyAll()\n\n Note over W: Wakes up, reacquires lock\n M-->>W: Check condition\n Note over W,M: balance >= 500, proceed\n W->>M: balance -= 500\n```\n\n\n---\n\n## 6. Multiple Conditions\n\nComplex monitors often need multiple conditions. A thread might wait for different reasons.\n\n### Example: Bounded Buffer\n\nA buffer that blocks when full (for producers) and when empty (for consumers).\n\n\n```mermaid\nflowchart TD\n subgraph BoundedBuffer[\"Bounded Buffer Monitor\"]\n L[Lock]:::orange\n NF[notFull Condition]:::secondary\n NE[notEmpty Condition]:::secondary\n B[(buffer)]:::purple\n end\n\n P[Producer]:::primary -->|put: wait on notFull| NF\n C[Consumer]:::primary -->|take: wait on notEmpty| NE\n\n NF --> B\n NE --> B\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\n### Implementation with Multiple Conditions\n\n\n```java\npublic class BoundedBuffer {\n private final Lock lock = new ReentrantLock();\n private final Condition notFull = lock.newCondition();\n private final Condition notEmpty = lock.newCondition();\n\n private final Object[] buffer;\n private int count, head, tail;\n\n public BoundedBuffer(int capacity) {\n buffer = new Object[capacity];\n }\n\n public void put(T item) throws InterruptedException {\n lock.lock();\n try {\n while (count == buffer.length) {\n notFull.await(); // Wait until not full\n }\n buffer[tail] = item;\n tail = (tail + 1) % buffer.length;\n count++;\n notEmpty.signal(); // Wake one waiting consumer\n } finally {\n lock.unlock();\n }\n }\n\n public T take() throws InterruptedException {\n lock.lock();\n try {\n while (count == 0) {\n notEmpty.await(); // Wait until not empty\n }\n T item = (T) buffer[head];\n head = (head + 1) % buffer.length;\n count--;\n notFull.signal(); // Wake one waiting producer\n return item;\n } finally {\n lock.unlock();\n }\n }\n}\n```\n\n\nUsing separate conditions is more efficient. `notFull.signal()` only wakes producers, not consumers.\n\n---\n\n## 7. Monitor Object vs External Locking\n\n### Comparison\n\n\n```mermaid\nflowchart LR\n subgraph External[\"External Locking\"]\n C1[Caller]:::primary -->|acquires| EL[Shared Lock]:::orange\n EL --> D1[(Data)]:::purple\n end\n\n subgraph Internal[\"Monitor Object\"]\n C2[Caller]:::primary --> M[Synchronized Method]:::orange\n M --> D2[(Private Data)]:::purple\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\n\n| ##### Aspect | ##### External Locking | ##### Monitor Object |\n| --- | --- | --- |\n| Lock management | Caller's job | Object's job |\n| Error risk | High | Low |\n| Flexibility | High | Moderate |\n| Encapsulation | Poor | Strong |\n| Composability | Difficult | Easier |\n\n\n### When to Use Each\n\n**Use Monitor Object when:**\n\n- Object has clear boundaries\n- All operations are well-defined\n- Simplicity is preferred\n\n**Use External Locking when:**\n\n- Multiple objects need atomic access\n- Lock ordering is critical\n- Fine-grained control is needed\n\n---\n\n## 8. Common Pitfalls\n\n### Pitfall 1: Exposing Internal State\n\n\n```java\n// Bad: exposing mutable internal state\npublic class BadMonitor {\n private List items = new ArrayList<>();\n\n public synchronized List getItems() {\n return items; // Caller can modify without lock!\n }\n}\n\n// Good: return copy or immutable view\npublic class GoodMonitor {\n private List items = new ArrayList<>();\n\n public synchronized List getItems() {\n return new ArrayList<>(items); // Defensive copy\n }\n}\n```\n\n\n### Pitfall 2: Calling External Methods While Holding Lock\n\n\n```java\n// Dangerous: calling unknown code while holding lock\npublic synchronized void process(Callback callback) {\n updateState();\n callback.onComplete(); // What if this acquires another lock?\n}\n```\n\n\nThis can cause deadlocks. The callback might try to acquire another lock that's waiting for this one.\n\n**Solution:** Release the lock before calling external code, or design to avoid such callbacks.\n\n### Pitfall 3: Long Operations Inside Monitor\n\n\n```java\n// Bad: holding lock during slow operation\npublic synchronized void save() {\n prepareData();\n writeToDatabase(); // Slow! Other threads blocked\n cleanup();\n}\n\n// Better: minimize lock scope\npublic void save() {\n Data data;\n synchronized (this) {\n data = prepareData();\n }\n writeToDatabase(data); // No lock held\n synchronized (this) {\n cleanup();\n }\n}\n```\n\n\n### Pitfall 4: Forgetting notifyAll\n\n\n```java\n// Bad: only notifies one thread\npublic synchronized void deposit(double amount) {\n balance += amount;\n notify(); // Only wakes one waiter\n}\n\n// Problem: multiple threads waiting to withdraw different amounts\n// Thread A waits for $500, Thread B waits for $100\n// Deposit $100, notify() wakes Thread A, but A still can't proceed\n// Thread B could proceed but isn't woken\n```\n\n\nUse `notifyAll()` unless you're certain only one thread should proceed.\n\n### Pitfall 5: Not Using Loop for Wait\n\n\n```java\n// Wrong\nif (condition) {\n wait();\n}\n\n// Correct\nwhile (condition) {\n wait();\n}\n```\n\n\nAlways use a `while` loop. Conditions may not hold after waking up.\n\n---\n\n## 9. Monitor Object in Different Languages\n\n### Java\n\n\n```java\n// Using synchronized keyword\npublic synchronized void method() {\n // Automatically thread-safe\n}\n\n// Using explicit locks\nprivate final Lock lock = new ReentrantLock();\nprivate final Condition condition = lock.newCondition();\n```\n\n\n### Python\n\n\n```python\nimport threading\n\nclass Monitor:\n def __init__(self):\n self._lock = threading.Lock()\n self._condition = threading.Condition(self._lock)\n self._value = 0\n\n def increment(self):\n with self._lock:\n self._value += 1\n\n def wait_for_value(self, target):\n with self._condition:\n while self._value < target:\n self._condition.wait()\n```\n\n\n### C++\n\n\n```cpp\n#include \n#include \n\nclass Monitor {\nprivate:\n std::mutex mtx;\n std::condition_variable cv;\n int value = 0;\n\npublic:\n void increment() {\n std::lock_guard lock(mtx);\n value++;\n cv.notify_all();\n }\n\n void waitForValue(int target) {\n std::unique_lock lock(mtx);\n cv.wait(lock, [this, target] { return value >= target; });\n }\n};\n```\n\n\n### Go\n\nGo uses channels more than monitors, but you can build one:\n\n\n```go\ntype Monitor struct {\n mu sync.Mutex\n cond *sync.Cond\n value int\n}\n\nfunc NewMonitor() *Monitor {\n m := &Monitor{}\n m.cond = sync.NewCond(&m.mu)\n return m\n}\n\nfunc (m *Monitor) Increment() {\n m.mu.Lock()\n defer m.mu.Unlock()\n m.value++\n m.cond.Broadcast()\n}\n```\n\n\n---\n\n## 10. When to Use in LLD Interviews\n\nThe Monitor Object Pattern appears in many interview scenarios:\n\n\n| ##### Problem | ##### Monitor Object Application |\n| --- | --- |\n| **Design a Thread-Safe Counter** | Counter object with synchronized increment/decrement |\n| **Design a Connection Pool** | Pool object manages connections with wait/notify |\n| **Design a Rate Limiter** | Limiter object tracks requests, blocks when exceeded |\n| **Design a Blocking Queue** | Queue with synchronized put/take, wait when full/empty |\n| **Design a Thread-Safe Cache** | Cache object with synchronized get/put operations |\n| **Design a Semaphore** | Semaphore object with acquire/release |\n\n\n### What to Mention in Interviews\n\n1. **Pattern Recognition:** \"This object needs thread-safe access. I'll use the Monitor Object Pattern to encapsulate synchronization.\"\n2. **Encapsulation Benefit:** \"Callers don't need to manage locks. The object guarantees thread safety internally.\"\n3. **Wait/Notify:** \"When threads need to wait for conditions, I'll use wait() to release the lock and sleep, then notify() to wake waiters.\"\n4. **Loop for Wait:** \"I always use a while loop around wait() to handle spurious wakeups.\"\n5. **Lock Scope:** \"I'll keep synchronized sections minimal to maximize concurrency.\"\n6. **Avoid Pitfalls:** \"I won't call external code while holding the lock to prevent deadlocks.\"\n\n---\n\n## 11. Summary\n\nThe **Monitor Object Pattern** encapsulates synchronization within an object, making thread safety the object's responsibility rather than the caller's.\n\n\n```mermaid\nflowchart TD\n subgraph Monitor[\"Monitor Object\"]\n direction TB\n LOCK[Intrinsic Lock]:::orange\n DATA[(Private State)]:::purple\n COND[Condition Variables]:::secondary\n\n M1[synchronized method1]:::primary\n M2[synchronized method2]:::primary\n\n M1 --> LOCK\n M2 --> LOCK\n LOCK --> DATA\n LOCK --> COND\n end\n\n T1[Thread 1]:::green --> M1\n T2[Thread 2]:::green --> M2\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Key Components\n\n\n| ##### Component | ##### Purpose |\n| --- | --- |\n| Private State | Data protected from direct access |\n| Synchronized Methods | Entry points that acquire lock automatically |\n| Intrinsic Lock | One per object, ensures mutual exclusion |\n| Condition Variables | Enable threads to wait for conditions |\n\n\n### Core Operations\n\n\n| ##### Operation | ##### Effect |\n| --- | --- |\n| `synchronized` | Acquires object lock before method execution |\n| `wait()` | Releases lock and sleeps until notified |\n| `notify()` | Wakes one waiting thread |\n| `notifyAll()` | Wakes all waiting threads |\n\n\n### Benefits\n\n- Encapsulates synchronization complexity\n- Reduces caller errors\n- Guarantees consistent locking\n- Supports condition synchronization\n\n### When to Use\n\n- Object has well-defined thread-safe operations\n- Multiple threads access shared state\n- Simplicity is preferred over fine-grained control\n- Operations need to wait for conditions\n\n### When NOT to Use\n\n- Operations span multiple objects\n- Fine-grained locking is required\n- Lock-free alternatives are available\n- Performance requires reader-writer distinction\n\nThe Monitor Object Pattern is fundamental to concurrent object-oriented design. It combines data encapsulation with synchronization, making it easier to write correct concurrent code.\n\n---\n\n## References\n\n- [Java Concurrency in Practice by Brian Goetz](undefined) - The definitive guide covering monitors and synchronization\n- [Pattern-Oriented Software Architecture Volume 2](undefined) - Original Monitor Object pattern description\n- [Java synchronized Keyword](undefined) - Official Java synchronization tutorial\n- [Condition Interface](undefined) - Java Condition documentation\n- [C++ Condition Variables](undefined) - C++ standard library reference\n- [Python threading Module](undefined) - Python threading documentation\n\n---\n\nThank you for reading!\n\nIf you found it valuable, hit a like and consider subscribing for more such content every week.\n\nIf you have any questions or suggestions, leave a comment.\n\nThis post is public so feel free to share it.\n\n[Share](undefined)\n\n---\n\n**P.S.** If you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](undefined)\n\n**There are [group discounts](https://blog.algomaster.io/subscribe?group=true), [gift options](https://blog.algomaster.io/subscribe?gift=true), and [referral bonuses](https://blog.algomaster.io/leaderboard) available.**\n\n---\n\nCheckout my **[Youtube channel](https://www.youtube.com/@ashishps_1/videos)** for more in-depth content.\n\nFollow me on **[LinkedIn](https://www.linkedin.com/in/ashishps1/)** and **[X](https://twitter.com/ashishps_1)** to stay updated.\n\nCheckout my **[GitHub repositories](https://github.com/ashishps1)** for free interview preparation resources.\n\nI hope you have a lovely day!\n\nSee you soon, Ashish","pageType":"lld-interviews"}

Monitor Object Pattern

Ashish Pratap Singh

Get Premium