Does Addressables.Release effectively unload assets when multiple handles reference the same bundle?

Short answer

No — releasing one handle does not unload a bundle that other handles still reference. Addressables unloads an AssetBundle only when the bundle's aggregate reference count reaches zero, which means every asset, scene, and instance obtained from that bundle (and every handle that acquired them) has been released. While any sibling asset from the same bundle is still held, the bundle stays in memory.

How the bundle count relates to asset handles

The bundle does not maintain an independent counter you can manipulate directly. Its lifetime is derived from the asset-level handles:

• Each load that resolves to a location inside the bundle (or a dependent bundle) increments the bundle's count.
• Each matching Addressables.Release decrements it.
• Loading the same address twice returns two handles that share one underlying operation and one count — both handles must be released. You can confirm this by logging handle.ReferenceCount after each load and release.

Conditions for a full unload

The underlying bundle is freed only when all of the following hold:

1. Every asset handle acquired from the bundle has been released exactly once, using the exact handle returned by the load (or a valid copy of it). Releasing a default-constructed or mismatched handle fails to decrement the count and logs an error — a common reason bundles never unload.
2. Objects created with InstantiateAsync have been freed with Addressables.ReleaseInstance. Calling Object.Destroy alone leaks the reference count.
3. Scenes loaded from the bundle have been unloaded with Addressables.UnloadSceneAsync.
4. Dependency bundles are also at zero. If your bundle depends on a shared-assets bundle, that dependency unloads only after every bundle and asset using it is released — so releasing one asset may free nothing observable.

Verifying it in your project

Enable Profiler Events in the Addressable Asset Settings, then open the Addressables Events/Profiler view. Load two assets from one bundle, release one handle, and confirm the bundle count stays above zero until the second release. Take Memory Profiler snapshots before and after the final release to confirm the bundle's native memory is actually freed — managed copies of loaded objects are tracked separately from the bundle file memory.

Caveats

Exact profiler window names, settings paths, and the internal unload mode (which affects whether lingering C# references to unloaded objects remain valid) vary between Addressables package versions. Check the documentation for your installed version, and keep a strict one-release-per-acquire discipline to avoid double-release errors.