PCAP Circular reference Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use weakref.WeakSet for the participants list in ChatRoom, so that when a User is no longer referenced elsewhere, it is automatically removed

  Why this is correct

  A WeakSet in ChatRoom holds only weak references to User objects, meaning the set does not participate in reference counting. When the last external strong reference to a User is deleted (e.g., the user logs out and the client connection closes), the object's refcount drops to zero and it is deallocated immediately, automatically removing it from the participants list without any manual cleanup. This breaks the reference cycle between ChatRoom and its participants because the weak reference never increments the reference count, so garbage collection is not needed for removal, and the cycle is resolved as soon as the external strong references vanish.

• ✗

  Increase the Python heap size using PYTHON_MALLOC_DEBUG to avoid memory issues

  Why it's wrong here

  Setting PYTHON_MALLOC_DEBUG or increasing the heap size only configures the allocator or gives the process more memory; it does not address the underlying cause of the memory leak, which is the reference cycle keeping dead User objects alive. Even with a larger heap, every disconnected user's User object and its ChatRoom reference remain strongly reachable through the participants list, so memory usage continues to grow unboundedly and will eventually exhaust even an enlarged heap. This approach treats the symptom (high memory pressure) rather than eliminating the stale references, and it also introduces debug-mode overhead that would degrade performance in production.

• ✗

  Store the ChatRoom reference in User using a weakref.ref, so that the cycle is broken

  Why it's wrong here

  Using weakref.ref for the ChatRoom reference in User would indeed break the cycle, but it solves the wrong half of the problem: the participant is still strongly held in ChatRoom's participants list, so when a user disconnects and external references disappear, the User object remains alive because the participants list keeps a strong reference to it. As a result, the weakref back to ChatRoom would not cause the User to be cleaned up; instead, the User lingers indefinitely until manual removal, and worse, if the ChatRoom were to be garbage-collected first (though it isn't because it is strongly referenced elsewhere), the User could suddenly lose its ChatRoom reference and raise ReferenceError when trying to use it. The appropriate fix is to make the container's reference weak (WeakSet), not the reverse direction.

• ✗

  Manually call gc.collect() every time a user disconnects

  Why it's wrong here

  Calling gc.collect() manually after a disconnect forces a full garbage collection pass, but it does nothing to prevent the reference cycle from being recreated with the next user; the cycle still exists in memory until the collector runs. Relying on manual collection is also nondeterministic and unscalable — invoking it frequently degrades performance due to stop-the-world pauses, while invoking it too rarely lets dead objects accumulate between calls. Moreover, in this pattern the cycle would never be collected in a timely manner if the participants list still holds strong references, so even a collections call would leave the User object alive unless the user is explicitly removed from the list first.

Go deeper

Related to this question