Reference counting associates each managed object with a count of how many owning references point to it. Creating an owning reference increments the count; destroying one decrements it. When the count reaches zero, the object can be reclaimed immediately.

For example, if two variables reference the same object, its count may be $2$. Releasing one changes the count to $1$; releasing the other changes it to $0$ and triggers destruction.

Reference counting has useful properties: reclamation is usually incremental, object destruction occurs at a predictable point, and the runtime need not periodically trace the entire live object graph.

Its fundamental weakness is cycles. If $A$ owns $B$ and $B$ owns $A$, both counts may remain positive even after no external reference reaches either object. The cycle is unreachable but ordinary reference counting cannot detect that fact.

Languages address this with techniques such as weak references, explicit distinctions between owning and non-owning edges, cycle detectors or hybrid tracing.

Reference counting also adds work to reference updates, often including synchronization for shared objects. It therefore represents a different memory-management trade-off from tracing garbage collection: local bookkeeping and prompt reclamation in exchange for update overhead and special treatment of cycles.