Set<AnyCancellable>调用removeAll()与遍历cancel()的区别、效果对比及强引用疑问

Great question—this is a super common point of confusion when working with Combine's AnyCancellable type, so let's break down the details clearly:

Core Behavioral Differences #

Let's start with what each operation actually does under the hood:

• observations.forEach { $0.cancel() }: This explicitly calls the cancel() method on every AnyCancellable in the set. This triggers the subscription's cancellation logic immediately—think stopping a network request, cleaning up resources, or terminating a data stream. After calling this, the AnyCancellable instances themselves still remain in the set until you remove them or the set is deallocated.
• observations.removeAll(): This removes all AnyCancellable instances from the set. If there are no other strong references to these instances, ARC will deallocate them. Critically, the AnyCancellable type's deinit method automatically calls cancel() when the instance is destroyed. So cancellation here is indirect, dependent on ARC's timing for reclaiming the objects.

Are Their Effects Fully Identical? #

In most everyday scenarios, the end result is the same: all subscriptions will be cancelled. But there's a key difference in timing:

• Explicit cancel() calls run immediately, so your subscription cleanup logic kicks in right away.
• removeAll() relies on ARC to deallocate the AnyCancellable instances, which might not happen until the current run loop cycle ends (or later, depending on other references). For most apps, this delay is negligible, but if you need immediate cancellation (e.g., stopping a pending network request when the user navigates away), explicit cancel() is more reliable.

What About Strong References/Cycles? #

This is where things get important. If your subscription creates a strong reference cycle (e.g., the subscription closure captures self strongly, and self holds the observations set), the two operations behave very differently:

• observations.removeAll(): Even though you remove the AnyCancellable instances from the set, the strong reference cycle means they still have an active reference (from the closure to self, and self indirectly referencing the subscription). ARC can't deallocate them, so cancel() is never called automatically. The subscription stays alive, and the cycle remains unbroken.
• observations.forEach { $0.cancel() }: Calling cancel() explicitly triggers the subscription's cleanup logic, which often breaks the reference cycle. For example, many Combine publishers will release their captured references when cancelled, allowing the AnyCancellable instances to be deallocated later (even if you don't remove them from the set immediately).

Which is the Better Practice? #

It depends on your context:

• If you've avoided strong reference cycles (e.g., using [weak self] in your subscription closures), removeAll() is absolutely the cleaner, more efficient choice. You don't need to iterate through the set, and ARC will handle cancellation automatically once the instances are deallocated.
• If you have potential cycle risks or need immediate cancellation, explicitly calling forEach { $0.cancel() } is safer. You can even pair it with removeAll() afterward to clean up the set:

  observations.forEach { $0.cancel() }
  observations.removeAll()
  

• As a general rule, prioritizing avoiding strong reference cycles in your subscriptions will make removeAll() the go-to option—keeping your code concise and relying on Combine's designed behavior.

内容的提问来源于stack exchange，提问作者villb