Ví dụ, nếu bạn có một lớp có tên là node, và node có một NSArray chứa các node con, và một tham chiếu duy nhất đến node cha của nó mà "chỉ hoạt động" với GC. Với ARC (và đếm tham chiếu thủ công), bạn gặp vấn đề. Một node cụ thể sẽ được tham chiếu từ các node con và cũng từ node cha của nó.

Như sau:

A -> [B1, B2, B3]
B1 -> A, B2 -> A, B3 -> A

Mọi thứ đều ổn khi bạn đang sử dụng A (ví dụ qua một biến cục bộ). Khi bạn đã hoàn thành và không sử dụng A nữa (cùng với B1/B2/B3), hệ thống GC cuối cùng sẽ quyết định xem nó có thể tìm thấy tất cả những gì nó có thể tìm từ ngăn xếp và thanh ghi CPU (registers). Nó sẽ không bao giờ tìm thấy A, B1, B2, B3, vì vậy nó sẽ kết thúc chúng và tái sử dụng bộ nhớ cho các đối tượng khác.

Khi sử dụng ARC hoặc MRC, khi bạn kết thúc việc sử dụng A, A sẽ có một refcount là 3 (B1, B2 và B3 đều tham chiếu đến nó), và B1/B2/B3 sẽ có một refcount là 1 (NSArray của A giữ một tham chiếu đến mỗi đối tượng). Vì vậy, tất cả những đối tượng này vẫn còn sống mặc dù không có gì có thể sử dụng chúng.

Giải pháp phổ biến là quyết định một trong những tham chiếu đó cần là weak (không đóng góp vào refcount). Điều đó sẽ hoạt động với một số mẫu sử dụng (usage pattern), ví dụ như nếu bạn chỉ tham chiếu B1/B2/B3 thông qua A. Tuy nhiên, với một số mẫu sử dụng khác, giải pháp này sẽ không thành công. Ví dụ, nếu đôi khi bạn giữ B1 và mong đợi có thể truy cập lên phần tử cha thông qua con trỏ parent và tìm thấy A. Với một weak reference, nếu bạn chỉ giữ B1, A có thể (và thường sẽ) biến mất, và kéo theo B2 và B3.

Bạn cũng có thể nói rằng ARC đặt ưu tiên lớn hơn về hiệu suất (hoặc có thể tính dự đoán), trong khi GC đặt ưu tiên lớn hơn về việc là một giải pháp tổng quát. Kết quả là GC yêu cầu CPU/bộ nhớ ít dự đoán hơn và có hiệu suất thấp hơn (thông thường) so với ARC, nhưng có thể xử lý bất kỳ mẫu sử dụng nào. ARC sẽ hoạt động tốt hơn cho rất nhiều mẫu sử dụng thông thường, nhưng với một số mẫu sử dụng (hợp lệ!), nó sẽ gặp vấn đề và không hoạt động.