Which one happens first?
Zeroing (nilling) weak variable.
deinit
Without looking at the documentation, nor implementation...
Only one order makes sense: nilling has to come first.
If deinitialization would start before nilling weak references ARC would suffer the good old resurrection problem (retaining an object that is in the process of being deallocated). That is not the case.
Here's my mental model of object destruction (again, not from the documentation, this can differ from real world):
last strong reference to an object goes away
retain count goes to zero (logically)
object is internally flagged for destruction, disabling any more new references
all weak references are nilled
unowned reference count is checked and traps if non-zero
deinit chain is called, possibly calling through to objc base classes dealloc
strong references to properties and ivars go away
objc side effects of dtor happen (associated objects, c++ destruction, ...)
memory is reclaimed
Step 1 through 4 happen atomically with regards to other threads potentially taking new strong references to the object.
Zeroing weak variable happens first. deinit happens later. At least in current implementation (Xcode 6.1, Swift 1.1) This is a result of observation of specific implementation, and I don't know how it is actually defined by the authors... If you have explicit source, please comment or answer.
There's also a related discussion in ADC forum.
Test code Avoid Playground when testing this to get correct lifecycle behaviour.
class AAA {
func test() {
}
}
var a1 = nil as AAA?
weak var a2 = nil as AAA?
class BBB: AAA {
var data = "Here be dragons."
override func test() {
println("test() called and a2 is now \(a2).")
}
deinit {
println("deinit called and a2 is now \(a2).")
}
}
a1 = BBB()
a2 = a1
a2!.test()
a1 = nil
Result:
test() called and a2 is now Optional(weak_deinit_order_comparison.BBB).
deinit called and a2 is now nil.
Then, the weak variable becomes nil before the deinit to be called.
Update
This pre-nilling is applied equally to unowned objects. Unowned object will become inaccessible at the point of deist just like weak, and trial to access unowned object at the deinit will crash the app.
Update 2
If you assign self to a weak var variable in deinit, it will become nil immediately. (Xcode Version 6.3.2 (6D2105))
class Foo {
init() {
}
deinit {
var a = self
weak var b = self
unowned var c = self
let d = Unmanaged.passUnretained(self)
println(a) // prints `Foo`.
println(b) // prints `nil`.
// println(c) // crashes.
println(d.takeUnretainedValue()) // prints `Foo`.
}
}
var f = Foo() as Foo?
f = nil
Related
I can see many examples of retain cycles in Swift. However many of them are incorrect, and reading the documentation does not make really simple examples that I can follow.
For the example:
class Dog {
func bark() {
print ("YAP")
}
}
var dog = Dog()
let doSomething = {
dog.bark()
}
doSomething()
Does the closure doSomething cause a retain cycle? I understand that the closure will execute quickly, but that is not the question. Does this inherently cause a retain cycle?
There is no retain cycle in the program you posted.
What is a retain cycle?
Consider each object (including each closure) in your program as one vertex in a directed graph. Consider a strong reference from object (or closure) A to object (or closure) B as an edge from A to B in the graph.
A retain cycle is a cycle in the graph: a path containing at least one edge (strong reference) that leads from a vertex back to itself.
For example, a typical retain cycle looks like this:
A view controller always has a strong reference to its view (if the view has been loaded). In this example, the view controller created a closure. The closure captured (has a strong reference to) the view controller. The view controller then stored the closure in a property on the view, creating a retain cycle.
What is the retain graph of your program?
Here's the retain graph of your program:
There are no retain cycles in this graph.
Here is another "example" that runs outside of playground to showcase a retain cycle with a closure:
class ClosureClassStrongRefCycle {
let str : String
lazy var printStr: () -> () = { // self is captured
print("\(self.str)")
}
init(str: String) {
self.str = str
}
deinit {
print("ClosureClassStrongRefCycle is being deallocated")
}
}
Now when you call your class like this :
do {
let myClassWithClosureStrongCycle = ClosureClassStrongRefCycle(str: "closure class strong cycle")
myClassWithClosureStrongCycle.printStr()
} // 'myClassWithClosureStrongCycle' is NEVER deallocated -> Strong reference cycle between this class and it's closure
the instance of ClosureClassStrongRefCycle retains itself because the closure within it retains self
finally if you want to get rid of the retain cycle, you can add unowned self like this :
lazy var printStr: () -> () = { [unowned self] in // Unowned copy of self inside printStr
print("\(self.str)")
}
I'm beginner in Swift. I have some questions need to resolve but I can't do it by myself.
Here is some problem for me:
class Author {
weak var book: Book?
deinit {
print("Dealloc Author")
}
}
class Book {
var author: Author?
deinit {
print("Dealloc Book")
}
}
var authorObj:Author? = Author()
authorObj!.book = Book()
authorObj!.book!.author = authorObj
This compiles fine:
class Author {
weak var book: Book?
deinit {
print("Dealloc Author")
}
}
class Book {
var author: Author?
deinit {
print("Dealloc Book")
}
}
var authorObj:Author? = Author()
authorObj!.book = Book()
authorObj!.book?.author = authorObj
authorObj = nil
So can you guys explain for me, what's different between ? and ! in authorObj!.book?.author = authorObj and
authorObj!.book!.author = authorObj?
I have two more questions:
authorObj is a strong reference same as authorObj.book.author, it's strong reference too? Because it dont have weak or unowned before var.
Only authorObj.book is weak reference. But when I assign authorObj to nil, all are deinited. Why? I assign only authorObj to nil but Author() instance still have 1 strong reference authorObj.book.author
So can you guys explain for me, what's different between ? and ! in
authorObj!.book?.author = authorObj and authorObj!.book!.author =
authorObj?
When you use ? to unwrap an optional it is referred to as optional chaining. If the optional is nil, the result of the entire chain will be nil. The advantage of using ? is that your app won't crash if the value being unwrapped is nil.
So:
authorObj!.book?.author = authorObj
will crash if authorObj is nil (because of the forced unwrap !).
and:
authorObj!.book!.author = authorObj
will crash if either authorObj or book is nil.
The safe way to write this would be:
authorObj?.book?.author = authorObj
If authorObj or book is nil, this will do nothing and it won't crash.
authorObj is a strong reference same as authorObj.book.author, it's
strong reference too? Because it dont have weak or unowned before var.
It only makes sense to talk about a single variable when talking about weak vs. strong. It doesn't make sense to ask if authorObj.book is weak; you can say that Author holds a weak reference to book.
Only authorObj.book is weak reference. But when I assign authorObj to
nil, all are deinited. Why? I assign only authorObj to nil but
Author() instance still have 1 strong reference authorObj.book.author
When you assign nil to authorObj, that was the last strong reference to authorObj, so Automatic Reference Counting (ARC) decrements the reference counter and then frees all of the references inside of authorObj. If those are strong references, it decrements the reference count and if that was the last reference to that object, the object is freed as well. If any other object is holding a weak reference to any object that is freed, then ARC will set that value to nil in all of the weak pointers.
To test this in a playground, put your commands inside a function called test and add print statements so that you can see when things happen.
class Author {
weak var book: Book?
deinit {
print("Dealloc Author")
}
}
class Book {
var author: Author?
deinit {
print("Dealloc Book")
}
}
func test() {
print("one")
var authorObj: Author? = Author()
print("two")
authorObj!.book = Book()
print("three")
authorObj!.book?.author = authorObj
print("four")
}
test()
Output:
one
two
Dealloc Book
three
four
Dealloc Author
The thing to note is that the Book is deallocated before step three. Why? Because there are no strong pointers to it. You allocated it and then assigned the only reference to it to a weak pointer inside of Author, so ARC immediately freed it.
That explains why authorObj!.book!.author = authorObj crashes, because authorObj!.book is nil since the Book which was just assigned to it has been freed.
Now, try assigning Book() to a local variable book:
func test() {
print("one")
var authorObj: Author? = Author()
print("two")
let book = Book()
authorObj!.book = book
print("three")
authorObj!.book?.author = authorObj
print("four")
authorObj = nil
print("five")
}
test()
This time, the output is quite different:
one
two
three
four
five
Dealloc Book
Dealloc Author
Now, the local variable book holds a strong reference to the Book that was allocated, so it doesn't get immediately freed.
Note, even though we assigned nil to authorObj in step four, it wasn't deallocated until after book was deallocated after step five.
The local variable book holds a strong reference to Book(), and Book holds a strong reference to Author, so when we assign nil to authorObj in step four, the authorObj can't be freed because book still holds a strong reference to it. When test ends, the local variable book is freed, so the strong reference to authorObj is freed, and finally authorObj can be deallocated since the last strong reference to it is gone.
Consider the following Class in swift that maintains a recursive relationship with itself
class OctupPromisable {
var promise: OctupPromisable?
weak var chainedPromise: OctupPromisable?
func then(octupPromisable: OctupPromisable) -> OctupPromisable? {
self.promise = octupPromisable
octupPromisable.chainedPromise = self
return self.promise
}
func start() {
if nil == self.chainedPromise {
self.fire(nil)
}else {
self.chainedPromise!.start()
}
}
}
used as such:
OctupPromisable()
.then(OctupPromisable())
.then(OctupPromisable())
.start()
when I call start with the chainedPromise being weak, it always results in the chainedPromise being nil and hence the start method never recurses.
Making the chainedPromise strong, causes the start method to recurse and work correctly. But in doing so am I not creating a strong cyclic relationship that leads to memory leak? If so, what can be done in order to achieve the recursion and yet avoid memory leak?
Thanks!
Make your chained process strong, but after you've used it, set it to nil. You're done with it, so you don't need to hold a strong reference any more. If there are no other strong references, the object will be deallocated.
If you don't need to keep references after execution, you could use a strong reference and release inner promises recursively, so when your first promise deallocate, it will not cause a memory leak.
I couldn't test the code but it goes like this:
class OctupPromisable {
weak var promise: OctupPromisable? // Make it weak to avoid reference cycle
var chainedPromise: OctupPromisable? // Make it a strong reference
func start() {
if nil == self.chainedPromise {
self.fire(nil)
} else {
self.chainedPromise!.start()
self.chainedPromise = nil // Will be deallocated after all 'start' calls
}
}
}
I am having hard time figuring out how to make sure when to use [weak self]/[unowned self] in the closure body. In the two scenarios shown below, according to me, it depends upon if the class B owns the passed closure or not.
Now If the implementation of class B is hidden I am not really sure how to decide on using [weak self]/[unowned self].
Can someone please help me understand how you will decide ?
/******** Scenario 1 **********/
class A {
var b:B?
let p = "Some Property of A"
init() {
print("Init of A")
self.b = B(closure: { (number) -> Void in
print(self.p) // capturing self but still no need to write [weak/unowned self]
print(number)
})
}
deinit {
print("Deinit of A")
}
}
// Suppose this is a library class whose implementation is hidden
class B {
init(closure:(Int->Void)) {
print("Init of B")
// ... do some work here
closure(20)
}
deinit {
print("Deinit of B")
}
}
var a:A? = A()
a = nil
Output:
// Init of A
// Init of B
// Some Property of A
// 20
// Deinit of A
// Deinit of B
Now the second scenario which will cause the reference cycle.
/******** Scenario 2 **********/
class A {
var b:B?
let p = "Some Property of A"
init() {
print("Init of A")
self.b = B(closure: { (number) -> Void in
print(self.p) // capturing self but NEED to write [weak/unowned self]
print(number)
})
}
deinit {
print("Deinit of A")
}
}
// Suppose this is a library class whose implementation is hidden
class B {
let closure:(Int->Void)
init(closure:(Int->Void)) {
print("Init of B")
self.closure = closure //class B owns the closure here
f()
}
func f() {
self.closure(20)
}
deinit {
print("Deinit of B")
}
}
var a:A? = A()
a = nil
The idea of "owning" is probably the wrong terminology here. Objective-C & Swift use ARC to manage memory. It's a system of references of varying types (strong, weak, and unowned). And it's important to note that unless a reference is marked as being weak or unowned, it's strong.
So, let's start by taking a look at your first example and pay attention to your references.
Below your class declarations, we have this code:
var a:A? = A()
a = nil
Because a isn't marked as weak or unowned, it's a strong reference to the object that we also create in the same line that we declare a. So, a is a strong reference to this object until a no longer points to that object (which in this case happens in the second line). And as we know, strong references prevent deallocation from happening.
Now let's dive into A's init method, which we're actually calling in this line.
init() {
print("Init of A")
self.b = B(closure: { (number) -> Void in
print(self.p)
print(number)
})
}
The first thing A's init does is print "Init of A", and that's the first thing we see looking at what is printed.
The next thing it does is assign a value to it's b property. It's b property also isn't marked as weak or unowned, so this is a strong reference.
And the value it is assigning to b is a newly constructed instance of the B class, which explains the second line we see printed: "Init of B", as that's the first line of B's initializer.
But B's initializer takes a closure. Here's the closure we've passed it:
{ (number) -> Void in
print(self.p) // capturing self but still no need to write [weak/unowned self]
print(number)
}
This block absolutely does hold a strong reference to self (in this case, the instance of a which printed "Init of A" earlier.
So, why isn't there a retain cycle? Well, let's look at B's initializer. What does it do with the closure?
class B {
init(closure:(Int->Void)) {
print("Init of B")
// ... do some work here
closure(20)
}
deinit {
print("Deinit of B")
}
}
So, when we instantiate an instance of B, it fires the closure, then forgets about it. No strong reference is ever made to the closure which we passed in.
So, let's take a look at our references:
global --strong--> a
closure --strong--> a
a --strong--> b
So, b will continue to have a strong reference and continue to exist for as long as a exists and maintains its strong reference to it. And a will continue to exist as long as at least one thing between your global reference and the closure continue to exist and maintain their strong reference to it.
But notice, nothing is keeping a strong reference to the closure. At least, not beyond the scope of whatever method it is used in.
The B initializer maintains a strong reference to the closure passed into it only until the end of the initializer.
So, when we write this line:
var a:A? = A()
By the time A() has returned, the variable a remains the only strong reference to a, and a remains the only strong reference to b. The closure, which had the potential to create a reference cycle no longer exists. Then, when we set a to be nil, we kill our strong reference to a.
a = nil
So, a deallocates. Upon that happening, there remain no strong references to b, so it also deallocates.
Your second example is different. In the second example, the implementation of A remains the same, but the implementation of B has changed. B now has this closure property which keeps a strong reference to whatever closure is passed into B's initializer.
So now, our references look like this:
global --strong--> a
closure --strong--> a
a --strong--> b
b --strong--> closure
So you can see, even if we break the global reference to a, there still exists a retain cycle:
a --> b --> closure --> a
If we do not make use of [weak self] or [unowned self], the closure absolutely has a strong reference to self. Whether or not that creates a retain cycle depends on what has strong references to the closure.
In order to determine that for 3rd party libraries, start by checking the source code or documentation. Outside of Apple, I don't currently know how to distribute a Swift library with private implementation that we can't investigate, and Apple's code is all well documented. But assuming the worst, assuming we really have no means, then treat any closure you pass to the third party library as something that the library will hold a strong reference to.
Even this doesn't necessarily mean we must always use [weak self] or [unowned self] in our closures.
If we notice in the example above, there are multiple ways to break the retain cycle. Remember what it looks like:
a -> b -> closure -> a
So, using [weak self] or [unowned self] would prevent the retain cycle as it would eliminate the closure's strong reference to a. But even if the closure maintains a strong reference to a, notice that if we break a's strong reference to b that the cycle breaks. Nothing holds a strong reference b so b will deallocate. That will leave nothing holding a strong reference to the closure, allowing the closure to deallocate, and then, nothing (at least within this cycle) is keeping a alive.
So if we pass a closure that does something like this...
{ (number) in
print(self.p)
print(number)
self.b = nil
}
That third line just so happens to break the cycle because now self no longer holds a strong reference to the b which holds the strong reference to the closure which holds the strong reference back to self.
Can someone explain when and when not to use a 'weak' assignment to a delegate pointer in Swift, and why?
My understanding is that if you use a protocol that is not defined as a class you cannot, nor want to, assign your delegate pointer to weak.
protocol MyStructProtocol{
//whatever
}
struct MyStruct {
var delegate: MyStructProtocol?
}
However, when your protocol is defined as a class type protocol then you DO want to set your delegate to a weak pointer?
protocol MyClassProtocol: class{
//whatever
}
class MyClass {
weak var delegate: MyClassProtocol?
}
Am I correct? In Apple's swift guide there class protocol examples aren't using weak assignments, but in my testing I'm seeing strong reference cycles if my delegates aren't weakly referenced.
You generally make class protocols weak to avoid the risk of a “strong reference cycle” (formerly known as a “retain cycle”). (Note, we now do that by adding the AnyObject protocol to a protocol’s inheritance list; see Class-Only Protocols; we do not use the class keyword anymore.) Failure to make the delegate weak does not mean that you inherently have a strong reference cycle, but merely that you could have one.
With struct types, though, the strong reference cycle risk is greatly diminished because struct types are not “reference” types, so it is harder to create strong reference cycle. But if the delegate object is a class object, then you might want to make the protocol a class protocol and make it weak.
In my opinion, making class delegates weak is only partially to alleviate the risk of a strong reference cycle. It also is a question of ownership. Most delegate protocols are situations where the object in question has no business claiming ownership over the delegate, but merely where the object in question is providing the ability to inform the delegate of something (or request something of it). E.g., if you want a view controller to have some text field delegate methods, the text field has no right to make a claim of ownership over the view controller.
As Rob said:
It's really a question of "ownership"
That's very true. 'Strong reference cycle' is all about getting that ownership right.
In the following example, we're not using weak var. Yet both objects will deallocate. Why?
protocol UserViewDelegate: class {
func userDidTap()
}
class Container {
let userView = UserView()
let delegate = Delegate()
init() {
userView.delegate = delegate
}
deinit {
print("container deallocated")
}
}
class UserView {
var delegate: UserViewDelegate?
func mockDelegatecall() {
delegate?.userDidTap()
}
deinit {
print("UserView deallocated")
}
}
class Delegate: UserViewDelegate {
func userDidTap() {
print("userDidTap Delegate callback in separate delegate object")
}
}
Usage:
var container: Container? = Container()
container?.userView.mockDelegatecall()
container = nil // will deallocate both objects
Memory ownership graph (doesn't have cycle)
+---------+container +--------+
| |
| |
| |
| |
| |
| |
v v
userView +------------------> delegate
In order to create a strong reference cycle, the cycle needs be complete. delegate needs to point back to container but it doesn't. So this isn't an issue. But purely for ownership reasons and as Rob has said here:
In an object hierarchy, a child object should not maintain strong references to the parent object. That is a red flag, indicating a strong reference cycle
So regardless of leaking, still use weak for your delegate objects.
In the following example, we're not using weak var. As a result neither of the classes will deallocate.
protocol UserViewDelegate: class {
func userDidTap()
}
class Container: UserViewDelegate {
let userView = UserView()
init() {
userView.delegate = self
}
func userDidTap() {
print("userDidTap Delegate callback by Container itself")
}
deinit {
print("container deallocated")
}
}
class UserView {
var delegate: UserViewDelegate?
func mockDelegatecall() {
delegate?.userDidTap()
}
deinit {
print("UserView deallocated")
}
}
Usage:
var container: Container? = Container()
container?.userView.mockDelegatecall()
container = nil // will NOT deallocate either objects
Memory ownership graph (has cycle)
+--------------------------------------------------+
| |
| |
+ v
container userview
^ |
| |
| |
+------+userView.delegate = self //container+------+
using weak var will avoid the strong reference cycle
Delegates should always generally be weak.
Lets say b is the delegate of a. Now a's delegate property is b.
In a case where you want b to release when c is gone
If c holds a strong reference to b and c deallocates, you want b to deallocate with c. However, using a strong delegate property in a, b will never get deallocated since a is holding on to b strongly. Using a weak reference, as soon as b loses the strong reference from c, b will dealloc when c deallocs.
Usually this is the intended behaviour, which is why you would want to use a weak property.