Reference counting: local release rules and cyclic retention

For a conventional reference-counted object, distinguish an owning strong handle from a temporary borrow or a non-owning observation. Only ownership operations specified by the API affect the count. Copying an Rc handle through its clone operation adds a strong owner without cloning the payload. Borrowing through that handle does not create another independently owning payload. The implementation also keeps metadata, and exact object layout and count optimizations vary. Treat a simple integer count as a teaching model rather than a universal description of every runtime.

An atomic reference count coordinates concurrent ownership updates; it does not make arbitrary fields inside the object safe for concurrent mutation. Rust's Arc and Rc differ in thread-related guarantees, while the referent's synchronization requirements remain separate. A decrement that destroys a value can run arbitrary cleanup code and release further objects. Design code so a destructor or callback cannot observe an inconsistent container state. In language runtimes with reentrant finalization behavior, releasing a reference can have effects well beyond subtracting an integer.

Draw two objects A and B, with A strongly owning B and B strongly owning A. Initially an external handle also owns A. Removing that external handle leaves one internal strong owner for each object. Neither count reaches zero, so plain reference counting cannot start their destruction. Their retention does not require another thread or a malfunctioning counter. It follows from the graph. A larger cycle can include callbacks, observer registrations, closures, and parent-child relationships that are less obvious than two explicit fields.

A weak edge describes a relationship without keeping the target payload alive. For example, a parent may strongly own children while each child weakly refers back to its parent. Access through a weak handle must attempt an upgrade and handle failure if the last strong owner has disappeared. Depending on the API, weak handles can retain a control block after payload destruction. They therefore avoid a particular ownership cycle without promising zero metadata retention. Alternatively, explicit lifecycle code can sever edges, and some runtimes combine reference counting with cycle detection.

When investigating retained objects, inspect ownership paths and their intended lifecycles before optimizing atomic increments. A permanent registry holding a strong handle is different from an isolated cycle, and both differ from a legitimately long-running request. Capture the path from a root or identify the closed strongly connected component. If the design intentionally keeps a shared cache, define eviction and size limits. Memory safety permits objects to remain live; it does not promise that every reachable or internally counted object is still useful to the application.

The probability lab offers a limited completion model. Suppose three independent external owners each release by a deadline with probability one half, and there are no internal strong edges. Set n=3 and p=0.5: the bar for three completions has probability one eighth. That is the probability all three have released under these assumptions. Raising p increases it. The lab does not manipulate reference counts, discover cycles, or model correlated owners. Add a strong A–B cycle on paper and explain why the same completion calculation no longer proves either payload can be destroyed.