Weak References and Finalizers

## Liveness is reachability, and not every reference counts A tracing collector cannot know which objects a program will touch next, so it approximates that with **reachability**. Starting from the roots — local variables on every thread's stack, machine registers, global and static storage, and handles held by native code — it follows references transitively. Everything in that closure is treated as live; everything outside it is garbage by definition. A **weak reference** is a reference the collector deliberately does not follow while computing that closure. It is a real object holding a real pointer, but it is invisible to the liveness argument. An object that can be reached from the roots only by passing through at least one weak link is therefore **not live**, however many weak references point at it, and the collector may reclaim it. ## The ladder of reference strengths Most collected runtimes expose a small ladder. The names differ between ecosystems and some runtimes do not offer every rung, but the shape is consistent: | strength | keeps the target alive? | when it is cleared | what it is for | |---|---|---|---| | strong | yes | never, while the path exists | ordinary ownership | | cleared under memory pressure | yes, at the collector's discretion | when the heap gets tight | recomputable caches | | weak | no | at the first collection that finds no strong path | side tables, observer registries | | post-mortem | no, and never returns the target | after the target is already unreachable | running cleanup for a dead object | The useful mental model is a ladder of *promises*, not of speeds. Strong promises the object stays. Weak promises nothing at all about lifetime, and only that you will be told — by getting an empty read — once the object is gone. ## What one collection cycle does 1. The collector computes the strong closure from the roots. 2. It finds objects outside that closure that have weak references pointing at them. 3. It clears those weak references as one step, so no thread can see the object through one reference after another has already emptied. 4. It reclaims the object — possibly in a later cycle, if the object also has cleanup work registered against it. The practical consequence of step 3 is that **clearing is not something your code does**. The program never calls a release; the reference simply starts reading as empty, on the collector's schedule. ## Reading a weak reference safely - **Read once, then hold strongly.** Promote the target to a local strong reference before using it. If you read the weak reference twice inside one operation, the second read can come back empty half-way through. - **Treat absence as normal control flow**, not an error. A cleared read means the object was not needed elsewhere any more, which is exactly what you asked for. - **Do not re-derive identity from the cleared reference.** Once cleared, it carries nothing about what used to be there; if you need an identifier after the fact, store a copy of it separately. ## What a weak reference is not - **Not an eviction policy.** Entries disappear when *other* parts of the program stop referring to their targets, which has nothing to do with how big the structure is, how often an entry is hit, or how expensive it is to rebuild. A structure of weakly held entries can still grow large. - **Not deterministic.** There is no bound on the delay between the last strong reference dropping and the clear. On a heap that never fills, the clear may never arrive. - **Not a dangling pointer.** This is the whole point of clearing: the runtime will not hand you a reference to reclaimed storage. - **Not free.** The reference objects themselves are heap objects the collector must manage, and discovering weakly reachable targets is extra work in every cycle. ## Where it is the right tool The honest use is **observing something whose lifetime someone else owns**: a side table of metadata attached to objects you did not create, a registry of listeners whose owners come and go, a recomputable lookup keyed by objects the request path already holds. In every one of those, the correct behaviour when the target is gone is to do nothing at all — and that is precisely what a cleared reference gives you. The failure case is the mirror image: a value you must be able to produce later, held only weakly because it felt like a cheap cache. That structure works perfectly in a test with a small heap and no collections, and starts missing in production for reasons that never show up in the code.