MENU
  1. ホーム
  2. Swift
  3. Swiftのクロージャで循環参照を防ぐ「weak」と「unowned」の使い方

Swiftのクロージャで循環参照を防ぐ「weak」と「unowned」の使い方

Swift

Swiftのプログラムにおいて、クロージャは非常に強力で便利な機能です。しかし、クロージャは同時に、メモリ管理において慎重な対応が必要な部分でもあります。特に、クロージャ内でオブジェクトへの強参照を保持したままにしてしまうと、循環参照が発生し、メモリリークの原因になります。この問題を防ぐためにSwiftは、「weak」と「unowned」という2つの参照修飾子を提供しています。本記事では、Swiftのクロージャ内で循環参照を防ぐための基本的な考え方と、「weak」と「unowned」の具体的な使い方について詳しく説明します。

目次

クロージャとは何か

クロージャは、Swiftにおいて「コードのブロック」として機能する要素で、他の関数やメソッドの引数として渡したり、変数に格納したりすることができます。クロージャは通常、関数やメソッド内で定義される「自己完結型」のコードで、周囲のコンテキストから変数や定数をキャプチャ（保持）する能力を持ちます。

クロージャの構文

Swiftのクロージャは、以下のようなシンプルな構文で定義されます。

let closure = { (引数) -> 戻り値の型 in
    実行されるコード
}

クロージャは、名前のない無名関数としても機能し、シンプルで柔軟な方法でコードを再利用したり、非同期処理を記述したりするために多用されます。例えば、配列のmapやfilterメソッドにクロージャを渡して、要素を操作するケースが典型的です。

循環参照が発生する理由

Swiftのメモリ管理では、循環参照（リファレンスサイクル）が発生すると、オブジェクトが解放されずメモリリークが起こる可能性があります。循環参照は、クロージャが定義されたコンテキストにあるオブジェクトをキャプチャし、そのオブジェクトが同じクロージャを強参照するときに発生します。この相互参照により、ARC（Automatic Reference Counting）がどちらのオブジェクトも解放できなくなり、メモリが無駄に消費されます。

クロージャがオブジェクトをキャプチャする仕組み

クロージャは、関数やメソッドの内部で使用される際、その周囲のスコープにある変数やオブジェクトをキャプチャ（保持）します。キャプチャされたオブジェクトは、クロージャが解放されるまで保持され続け、解放されないとメモリリークが発生する可能性があります。

循環参照の例

次のコードは、循環参照が発生する典型的な例です。

class Person {
    var name: String
    var printName: (() -> Void)?

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

    func setupPrintName() {
        printName = {
            print(self.name)
        }
    }

    deinit {
        print("\(name) is being deinitialized")
    }
}

上記の例では、PersonクラスのprintNameプロパティにクロージャが格納され、そのクロージャ内でselfを強参照しています。これにより、Personインスタンスが解放されず、循環参照が発生します。

メモリ管理における強参照と弱参照

Swiftのメモリ管理は、Automatic Reference Counting（ARC）という仕組みに基づいています。ARCは、オブジェクトが参照されている回数（参照カウント）を自動的に管理し、参照がなくなったオブジェクトを解放します。しかし、循環参照が発生すると、このカウントが正しく減少せず、メモリリークの原因となります。ここで、強参照と弱参照（weak, unowned）という概念が重要になります。

強参照とは

通常、オブジェクトを参照する際には強参照（strong reference）が使用されます。強参照は、参照されているオブジェクトのライフサイクルを維持する役割があります。具体的には、変数や定数がオブジェクトを強参照している限り、そのオブジェクトはメモリから解放されません。

class A {
    var b: B?
}

class B {
    var a: A?
}

上記の例では、クラスAとクラスBが互いに強参照し合っており、循環参照が発生します。この場合、どちらのオブジェクトも参照カウントが0にならず、メモリから解放されません。

弱参照とは

弱参照（weak reference）は、強参照とは異なり、オブジェクトの参照カウントを増加させません。これにより、強参照がなくなればオブジェクトが解放されます。弱参照は、オブジェクトが解放された場合に自動的にnilになるため、安全に使用できます。循環参照を防ぐために、クロージャ内でオブジェクトをキャプチャする際にはweakやunownedを使うことが推奨されます。

weak var weakSelf = self

このようにして、オブジェクトが循環参照を引き起こさないようにすることが可能です。

unowned参照

一方、unownedは弱参照と同様にオブジェクトを参照しますが、参照が無効になってもnilにはなりません。unownedは、オブジェクトが必ず解放されることが分かっている場合に使用することが適していますが、解放済みのオブジェクトにアクセスするとクラッシュする可能性があるため、注意が必要です。

weakの使い方


weakキーワードは、Swiftで循環参照を防ぐために使われる代表的な方法の一つです。特に、クロージャやクラスインスタンス間で相互参照が起きる場合、weakを使って参照を弱めることで、ARC（Automatic Reference Counting）によるメモリリークを防ぎます。weakを使用すると、オブジェクトのライフサイクルが終了した際、参照が自動的にnilになるため、参照され続けることによるメモリの保持がなくなります。

weakの使用方法


weakは、通常クラスインスタンスを参照する際に使用され、オプショナル型のプロパティや変数として定義する必要があります。なぜなら、weak参照は参照先がnilになる可能性があるからです。

以下のコードは、weakを使用して循環参照を防ぐ例です。

class Person {
    var name: String
    var printName: (() -> Void)?

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

    func setupPrintName() {
        printName = { [weak self] in
            guard let self = self else { return }
            print(self.name)
        }
    }

    deinit {
        print("\(name) is being deinitialized")
    }
}

この例では、setupPrintNameメソッド内のクロージャでselfをキャプチャしていますが、[weak self]を指定することで、クロージャはselfを強参照しません。もしPersonインスタンスが解放された場合、クロージャ内のselfはnilになり、参照が残らず循環参照を回避できます。

weakの使用シナリオ


weakを使用する典型的なシナリオは次の通りです：

  • デリゲートパターン: クロージャが、デリゲートやプロトコルのメソッドを実行するとき、デリゲート側のオブジェクトを弱参照にすることが推奨されます。
  • 非同期クロージャ: 非同期操作のためにクロージャを設定する場合、操作が完了するまでインスタンスがメモリに残るよう、weakを使用して循環参照を防ぎます。

weakを適切に使うことで、プログラムのメモリ管理を改善し、クロージャを安全に利用できます。

unownedの使い方


unownedキーワードは、weakと同様に循環参照を防ぐために使用されますが、unownedにはいくつかの重要な違いがあります。weakが参照先オブジェクトのライフサイクルが終わるとnilになるのに対し、unownedは参照先が解放されてもnilにはならず、そのままの参照を保持します。unownedを使用する場合、参照先が必ず生存していることが前提となるため、解放されたオブジェクトにアクセスしようとするとプログラムがクラッシュします。

unownedの使用方法


unownedは、特に循環参照のリスクがある場合に使われますが、オブジェクトのライフサイクルが同期しているときや、明らかに参照先が存在していることが確実である場合に使用するのが適しています。

以下の例は、unownedを使った循環参照の回避例です。

class Person {
    var name: String
    var apartment: Apartment?

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

    deinit {
        print("\(name) is being deinitialized")
    }
}

class Apartment {
    var tenant: Person

    init(tenant: Person) {
        self.tenant = tenant
    }

    deinit {
        print("Apartment is being deinitialized")
    }
}

var john: Person? = Person(name: "John")
var apt: Apartment? = Apartment(tenant: john!)

john?.apartment = apt

apt = nil
john = nil

上記のコードでは、PersonとApartmentクラスがお互いを強参照しているため、メモリリークが発生します。この場合、unownedを使って、次のように循環参照を防ぐことができます。

class Apartment {
    unowned var tenant: Person

    init(tenant: Person) {
        self.tenant = tenant
    }

    deinit {
        print("Apartment is being deinitialized")
    }
}

このように、unownedを使用すると、tenantが必ず存在していることが前提となり、nilのチェックが不要なケースで効率的に参照を持ち続けることができます。

unownedを使うべきケース


unownedは、次のようなケースで有効です。

  • ライフサイクルが密接に結びついているオブジェクト間: 例えば、親子関係のように、あるオブジェクトが必ず他のオブジェクトの寿命に依存している場合に使用します。親オブジェクトが存在する限り、子オブジェクトは必ず存在するときに便利です。
  • 循環参照を回避する場合で、オブジェクトが必ず解放されないことが確実: メモリ解放のタイミングが一致しているときに適しています。

注意点として、unownedを使用する場合は、参照先オブジェクトが予期せず解放されているとプログラムがクラッシュする可能性があるため、非常に慎重な使用が求められます。

weakとunownedの使い分け


weakとunownedは、どちらもSwiftで循環参照を防ぐための重要なツールですが、それぞれの適用場面や特性は異なります。これらを適切に使い分けることが、効率的なメモリ管理において非常に重要です。どちらを使用すべきかは、参照するオブジェクトのライフサイクルと解放タイミングによって決まります。

weakを使うべき場面


weakは、参照するオブジェクトが解放される可能性があり、かつその解放を考慮する必要がある場合に使用します。weak参照は、参照先が解放されると自動的にnilになり、参照カウントを増やさずにオブジェクトを安全に保持できます。

  • 参照先が解放される可能性がある: たとえば、あるビューコントローラが非同期処理を行う際、そのクロージャ内で自身（self）をキャプチャするときに、ビューが解放される可能性がある場合にはweakを使うことが適しています。
self.someAsyncFunction { [weak self] in
    guard let self = self else { return }
    self.doSomething()
}

このように、weakを使えば、オブジェクトが解放されてもnilチェックによって安全に処理を行うことができます。

unownedを使うべき場面


unownedは、参照するオブジェクトが解放されることがない、もしくは参照先オブジェクトと自身のライフサイクルが同じ場合に使用します。unownedはnilにならないため、解放されたオブジェクトにアクセスしようとするとクラッシュしますが、参照カウントを増やさないという点ではweakと同じです。

  • オブジェクトの寿命が明確に一致する場合: たとえば、親オブジェクトが生存している限り、子オブジェクトも必ず生存している状況においては、unownedが適しています。メモリの管理がより効率的になります。
class Child {
    unowned var parent: Parent

    init(parent: Parent) {
        self.parent = parent
    }
}

このような場合、parentが必ず解放されない限り、Childはparentを安全に参照できます。

weakとunownedの使い分けの判断基準


どちらを使うか迷った場合は、次の判断基準を参考にしてください。

  • 解放されるかもしれない場合はweakを使用し、参照先が解放される可能性がある場合に備えます。
  • 解放されないことが保証されている場合はunownedを使用して、より効率的なメモリ管理を行います。

また、unownedは参照先が解放されるとクラッシュするリスクがあるため、解放される可能性がある場合にはweakを選択するのが安全です。

循環参照の実際の例


循環参照は、クロージャがオブジェクトをキャプチャする際に発生する代表的な問題です。ここでは、循環参照が発生する典型的な例を示し、その問題点と解決策を具体的に見ていきます。

循環参照のコード例


以下のコードは、PersonクラスとApartmentクラスが互いに強参照し合い、循環参照が発生する例です。

class Person {
    var name: String
    var apartment: Apartment?

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

    deinit {
        print("\(name) is being deinitialized")
    }
}

class Apartment {
    var tenant: Person?

    init() {}

    deinit {
        print("Apartment is being deinitialized")
    }
}

このコードでは、PersonクラスのapartmentプロパティがApartmentクラスを参照し、同時にApartmentクラスのtenantプロパティがPersonを参照しています。これにより、両者が強参照し合い、どちらも解放されない状況が発生します。

var john: Person? = Person(name: "John")
var apt: Apartment? = Apartment()

john?.apartment = apt
apt?.tenant = john

john = nil
apt = nil

このように、お互いが強参照しているため、johnやaptがnilに設定されても、メモリから解放されることはありません。結果として、循環参照によるメモリリークが発生します。

weakを使った解決策


この問題を解決するためには、どちらか一方の参照を弱参照にする必要があります。例えば、Apartmentクラスのtenantプロパティをweak参照に変更することで、循環参照を防ぐことができます。

class Apartment {
    weak var tenant: Person?

    init() {}

    deinit {
        print("Apartment is being deinitialized")
    }
}

これにより、Personオブジェクトが解放されるとき、Apartmentのtenantプロパティはnilになり、循環参照が発生しなくなります。

var john: Person? = Person(name: "John")
var apt: Apartment? = Apartment()

john?.apartment = apt
apt?.tenant = john

john = nil // Personが解放される
apt = nil  // Apartmentも解放される

この修正後、johnやaptがnilに設定されたとき、それぞれがメモリから正常に解放され、循環参照が発生しません。

unownedを使った別の解決策


もう一つの方法として、unownedを使用することもできます。unownedは、参照先が必ず存在すると確信できる場合に使います。例えば、PersonとApartmentのライフサイクルが必ず同じである場合には、unownedを使うことで、さらなるメモリ効率を追求できます。

class Apartment {
    unowned var tenant: Person

    init(tenant: Person) {
        self.tenant = tenant
    }

    deinit {
        print("Apartment is being deinitialized")
    }
}

このように、weakまたはunownedを使って適切に参照を設定することで、循環参照を回避し、メモリリークを防ぐことができます。

応用: メモリリークのデバッグ方法


循環参照やその他のメモリリークを検出し、解消することは、Swiftプログラムのパフォーマンスを保つために重要です。メモリリークは、開発中には気づかないことが多く、特にクロージャや非同期処理を多用する場合、思わぬ箇所で発生することがあります。このセクションでは、メモリリークをデバッグするための具体的な方法とツールについて解説します。

Xcodeのメモリグラフデバッグツールを使用する


Xcodeには、メモリリークを視覚的に確認できる「メモリグラフデバッグツール」が組み込まれています。このツールを使うことで、オブジェクトの循環参照や不要なメモリ保持の原因を簡単に特定できます。

メモリグラフを使用する手順

  1. Xcodeでプロジェクトをビルドし、デバッグモードでアプリを実行します。
  2. 実行中に、Xcodeのデバッグバーにあるメモリアイコン（エレファントのアイコン）をクリックして、メモリグラフを生成します。
  3. 「メモリグラフビューア」で、メモリに保持されているオブジェクトとその参照関係がグラフ形式で表示されます。
  4. 循環参照が発生している場合、オブジェクト間の参照が循環していることが視覚的に示されます。強参照や弱参照の違いも色分けされるため、問題の特定が容易です。

メモリリークの兆候を見逃さない


次に、コードに問題がある場合、どのような兆候が見られるかを確認します。メモリリークが疑われる場合、以下のような現象が発生することが多いです。

  • アプリの動作が徐々に遅くなる: メモリリークがあると、不要なメモリが保持され続け、アプリが重くなることがあります。
  • オブジェクトのdeinitが呼ばれない: クラスにdeinitメソッドを定義して、オブジェクトが解放されるかどうかを確認することができます。解放されない場合は、循環参照が原因である可能性が高いです。
deinit {
    print("Object is being deinitialized")
}

deinitが呼ばれない場合、そのオブジェクトはどこかで強参照されたままになっていることが考えられます。

Instrumentsを使ったメモリリークの検出


Xcodeに付属している「Instruments」は、メモリ使用状況やリークを詳細に分析できる強力なツールです。Instrumentsを使って、アプリのパフォーマンスを測定し、メモリリークをリアルタイムで確認することができます。

Instrumentsでメモリリークを検出する手順

  1. Xcodeで「Product」→「Profile」を選択し、Instrumentsを起動します。
  2. 使用するテンプレートとして「Leaks」を選択し、アプリを実行します。
  3. アプリの使用中にメモリリークが発生した場合、Leaksトラックにその情報が表示されます。
  4. Instrumentsのデータを分析し、リークの原因となっているオブジェクトや循環参照の場所を特定します。

メモリリークを防ぐためのベストプラクティス

  • クロージャ内でのweakやunownedの使用: 先に述べた通り、クロージャがオブジェクトをキャプチャする際、循環参照を避けるためにweakやunownedを適切に使うことが重要です。
  • デリゲートのweak参照: デリゲートパターンを使用する場合、デリゲートオブジェクトをweak参照にすることが推奨されます。これにより、デリゲートのライフサイクルに関わる循環参照を防げます。

これらのツールとベストプラクティスを駆使することで、メモリリークを効果的に検出し、防止することが可能です。

演習問題: weakとunownedの使い方を学ぶ


ここでは、weakとunownedの違いを理解し、実際に使い分けるための演習問題を紹介します。この演習を通じて、循環参照を防ぎながら安全にクロージャを使用する方法を実践的に学びましょう。

問題1: weakを使用して循環参照を解消する


次のコードには、PersonとApartmentの間で循環参照が発生しています。この循環参照を解消するために、weakを使用して正しいメモリ管理を実装してください。

class Person {
    var name: String
    var apartment: Apartment?

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

    deinit {
        print("\(name) is being deinitialized")
    }
}

class Apartment {
    var tenant: Person?

    init() {}

    deinit {
        print("Apartment is being deinitialized")
    }
}

var john: Person? = Person(name: "John")
var apt: Apartment? = Apartment()

john?.apartment = apt
apt?.tenant = john

john = nil
apt = nil

解答例
Apartmentクラスのtenantプロパティをweakに変更して、循環参照を解消します。

class Apartment {
    weak var tenant: Person?

    init() {}

    deinit {
        print("Apartment is being deinitialized")
    }
}

これにより、Personが解放されたときにApartmentのtenantプロパティがnilとなり、循環参照を回避できます。

問題2: unownedを使ってメモリ効率を高める


次に、weakの代わりにunownedを使用してメモリ管理を効率化する方法を学びましょう。次のコードでは、ChildとParentクラスの関係を表現しています。ここで、親が存在する限り子も存在することが保証されている場合、weakではなくunownedを使用してメモリ効率を改善してください。

class Parent {
    var child: Child?

    init() {}

    deinit {
        print("Parent is being deinitialized")
    }
}

class Child {
    var parent: Parent

    init(parent: Parent) {
        self.parent = parent
    }

    deinit {
        print("Child is being deinitialized")
    }
}

解答例
Childクラスのparentプロパティをunownedに変更します。これにより、Parentが存在する限りChildも存在するという前提のもと、メモリ効率を向上させることができます。

class Child {
    unowned var parent: Parent

    init(parent: Parent) {
        self.parent = parent
    }

    deinit {
        print("Child is being deinitialized")
    }
}

この例では、Parentが存在する間、ChildはunownedでParentを参照し、Parentが解放されると同時にChildも解放されることが保証されます。

問題3: weakとunownedの使い分けを試す


次に、複数のオブジェクト間での参照において、weakとunownedを適切に使い分けるケースを想定した問題です。

問題
以下の状況を考えてください：

  • ManagerクラスがEmployeeクラスを所有します。
  • Employeeクラスは、必ずManagerが存在することを前提としています。
  • Managerが解放された場合、Employeeも同時に解放される必要があります。

この関係を表すコードを書き、weakとunownedの使い分けを実装してください。

解答例

class Manager {
    var employee: Employee?

    init() {}

    deinit {
        print("Manager is being deinitialized")
    }
}

class Employee {
    unowned var manager: Manager

    init(manager: Manager) {
        self.manager = manager
    }

    deinit {
        print("Employee is being deinitialized")
    }
}

var manager: Manager? = Manager()
var employee: Employee? = Employee(manager: manager!)

manager?.employee = employee

manager = nil
employee = nil

この問題では、Employeeのmanager参照にunownedを使うことで、Managerが存在しなくなると同時にEmployeeも解放されることが保証されています。weakを使う場合とは異なり、nilチェックは不要です。

これらの演習問題を通じて、weakとunownedの使い方をより深く理解できたはずです。実際にコードを書いて試してみることで、循環参照を防ぎながら効率的なメモリ管理ができるようになります。

SwiftのARC（Automatic Reference Counting）の仕組み


Swiftのメモリ管理は、ARC（Automatic Reference Counting）という仕組みによって自動的に行われます。ARCは、オブジェクトのライフサイクルを管理し、メモリを効率的に使うために、参照カウントを基にオブジェクトの解放を行います。このセクションでは、ARCの基本的な仕組みと、クロージャとの関連について解説します。

ARCの基本原理


ARCは、オブジェクトがメモリに保持される参照回数（参照カウント）を管理します。新しいオブジェクトが作成されると、参照カウントが1になります。そのオブジェクトが別の場所で参照されるたびにカウントが増え、参照が解除されるとカウントが減ります。参照カウントが0になると、そのオブジェクトはメモリから解放されます。

class Person {
    var name: String

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

    deinit {
        print("\(name) is being deinitialized")
    }
}

var person1: Person? = Person(name: "John")
var person2 = person1  // 参照カウントが増える

person1 = nil  // まだ参照が残っているため解放されない
person2 = nil  // 参照カウントが0になるので解放される

上記の例では、person1とperson2が同じPersonオブジェクトを参照しています。両方の変数がnilになると、参照カウントが0となり、オブジェクトが解放されます。

クロージャとARCの関係


クロージャは、外部の変数やオブジェクトをキャプチャ（保持）する能力があります。このとき、クロージャが保持しているオブジェクトを強参照してしまうと、クロージャとオブジェクトの間で循環参照が発生し、メモリが解放されなくなる問題が起こります。

class Person {
    var name: String
    var printName: (() -> Void)?

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

    func setupPrintName() {
        printName = {
            print(self.name)
        }
    }

    deinit {
        print("\(name) is being deinitialized")
    }
}

var person: Person? = Person(name: "John")
person?.setupPrintName()
person = nil  // 循環参照があるため解放されない

この例では、クロージャがselfを強参照しており、Personオブジェクトが解放されないという問題が発生しています。

ARCと循環参照の解決策


このような循環参照を解決するために、weakやunownedを使用します。これらを使用することで、クロージャがオブジェクトを強参照しないようにし、循環参照を防ぎます。

class Person {
    var name: String
    var printName: (() -> Void)?

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

    func setupPrintName() {
        printName = { [weak self] in
            guard let self = self else { return }
            print(self.name)
        }
    }

    deinit {
        print("\(name) is being deinitialized")
    }
}

var person: Person? = Person(name: "John")
person?.setupPrintName()
person = nil  // 循環参照がないため解放される

このコードでは、[weak self]を使用してクロージャ内でselfを弱参照しています。これにより、Personオブジェクトが解放されると、クロージャ内のselfは自動的にnilとなり、循環参照が発生しなくなります。

ARCとパフォーマンス


ARCは非常に効率的にメモリ管理を行いますが、大量のオブジェクトが一度に作成・解放されると、CPU負荷が高まることがあります。このため、メモリ管理を最適化するために、weakやunownedを正しく使うことが重要です。適切な参照管理によって、メモリリークやパフォーマンスの低下を防ぐことができます。

ARCの仕組みを理解し、適切に利用することで、Swiftプログラムのメモリ管理が効率的に行えます。

まとめ


本記事では、Swiftにおけるクロージャの循環参照問題と、それを防ぐための「weak」および「unowned」の使い方について詳しく解説しました。weakはオブジェクトの解放があり得る場合に使用し、参照がnilになることを考慮します。一方、unownedはオブジェクトの解放が確実にない場合に使用し、効率的なメモリ管理を実現します。これらの仕組みを適切に使い分けることで、Swiftプログラムのメモリリークを防ぎ、パフォーマンスを維持することができます。

Swift
メモリ管理 クロージャ Swift weak unowned

コメント

コメントする

目次