与 Deinit 和内存泄漏混淆

Question

I am trying to learn about Memory Management in iOS development. I read this article / tutorial: Make Memory Management Great Again

In that tutorial, there is a deinit method inside a class, like this:

class Human {
  var passport: Passport?
  let name: String

  init(name: String) {
    self.name = name
  }

  deinit {
    print("I'm gone, friends")
  }
}

After we make an instance, the reference count is one because it is a strong reference. until this step, I understand.

var bob: Human? = Human(name: "Bob Lee")

It is said that when we make an instance, it actually takes space in our RAM.

If we assign nil to 'bob' variable, the deinit will print ("I'm gone, friends"), and the relationship no longer exists, so the reference count becomes 0 which causes both objects to be deallocated.

The things that makes me confused:

1. in my actual code / from tutorial I follow, I never see 'deinit' in my class, and I never assign nil to the instance, so the object will never be deallocated and it will take space in my memory like fat? should I write deinit in my code? because I think if over limited of space, it would be filled with data objects and eventually my app would break

2. it is said that:

Automatic Reference Counting to indicate whether an object is still being used or no longer needed

No longer needed? What does it mean?

Answer 1

Just to clarify from your example:

var bob: Human? = Human(name: "Bob Lee")
// bob now has a reference count of 1
// the memory at the bob location is ready to access and/or modify
// this means bob is still alive and we can find out things about him

print(bob!.name) 
// prints "Bob Lee"

bob = nil
// deinit called, "I'm gone, friends"
// bob now has a reference count of 0, and ARC has released the object that was stored here
// we cannot find out anything about bob
// the memory at the location of bob is now released

print(bob!.name)
// Error: Unexpectedly found nil while unwrapping optional value

To answer your questions:

1. If you never need to assign nil to bob (it might not make sense depending on the context), you should assign the type of bob to be Human , not Human? . This means that bob can never, and will never be nil, and makes your code much easier to reason about. This does not mean that the Human object located at bob will never be gone from memory though. If bob is, for example, inside a view controller that at some point is deallocated (if the user navigates away from that VC or the app is closed), bob will of course also be deallocated by the system.

2. "No longer needed" means 'needed' from an access perspective from your code. If bob is set to nil, why would you need to access information about him again? You don't, so the object located at bob has its reference count reduces to 0, is no longer needed , and is deallocated.

I hope I could clear some things up for you.