シングルトンライクなコードでnull判定する理由

前提・実現したいこと

以下のようなシングルトンみたなコード(それとも、これもシングルトンのコードと言えますか？)で、
null判定する理由は何でしょうか？
ご教示お願いします。

C#
1  using System.Collections;
2  using System.Collections.Generic;
3  using UnityEngine;
4
5  public class ItemBox : MonoBehaviour
6  {
7      public static ItemBox instance;
8
9      void Awake()
10      {
11          if (instance == null)
12          {
13              instance = this;
14          }
15      }
16
17      public void SetItem()
18      {
19          Debug.Log("SetItem");
20      }
21
22  }

試したこと

以下のコードを試す前までは、
staticな変数は、ゲーム全体に変数が保存されることになるので、シーンが遷移してゲームオブジェクトが破棄されても
変数は生き残るようになっていると認識していたため、
シーンをリロードした際に残っているinstanceがnullでないので、
そのために、「if (instance == null)」の条件判定が必要と思っていました。
しかし、以下のコードを試してみると、

C#
1using System.Collections;
2using System.Collections.Generic;
3using UnityEngine;
4using UnityEngine.SceneManagement;  //追記。
5
6
7public class ItemBox : MonoBehaviour
8{
9    public static ItemBox instance;
10    public static int i = 5;
11
12    void Awake()
13    {
14        Debug.Log(i);
15        if (instance == null)
16        {
17            Debug.Log(null);
18            instance = this;
19        }else{
20            Debug.Log("exist");
21        }
22    }
23
24    void Start()
25    {
26        i = 10;
27        Invoke("ReloadScene", 2.0f);
28    }
29
30    void ReloadScene()
31    {
32        SceneManager.LoadScene(SceneManager.GetActiveScene().buildIndex);
33        Debug.Log("Reload");
34    }
35
36    public void SetItem()
37    {
38        Debug.Log("SetItem");
39    }
40
41}

以下のようなログとなってしまいました。

5
Null
SetItem
Reload
10
Null
SetItem

シーンをリロードしたら、instanceはnullとなってしまっているようです。
staticな変数でもシーンをリロードしたら、nullとなってしまうのでしょうか？
しかし、同じくstaticな変数iを用意して取っているログを見たところ、
シーンリロード時には値が10となっているので、リロード前の変数が残っているようにも見えます。
このことから、staticな変数がシーンを跨ぐと生き残るのか、破棄されるのかよくわからない状態です。
また、質問の前提に書きましたが、このシングルトンみたいなコードで「if (instance == null)」と判定する理由はなんでしょうか？
上記検証でわからなくなってしまったことに加えて、他に考えられることとしては、
上記シングルトンみたいなコードを複数のゲームオブジェクトにアタッチしたり、
1つだけのゲームオブジェクトにアタッチした場合でも、
Instantiateメソッド等でそのゲームオブジェクトを複数生成した場合に、
「if (instance == null)」の判定が生かされるようにも思えますが、
そもそもシングルトンみたいなコードを複数のゲームオブジェクトにアタッチしたり、
Instantiateメソッド等で複製すること自体があまりないように思えるので
(あったとしても開発者側(人間側)の凡ミスのはず)、
そのチェックのために行っているnull判定ではないように思えてしまいます。

行動規範の内容に同意します

回答2件

instance == null で判定しているからです。

Unityのnullはnullじゃないかもしれない - Qiita

投稿2021/10/10 00:00

Zuishin

総合スコア28669

Zuishin

2021/10/10 00:13 編集

C# には演算子のオーバーロードという機能があり、演算子の役割を書き換えることができます。 Monobehavior はこれを使って == を書き換えており、シーン変更などで破壊されたオブジェクトを null と判定するようにしているため、このようなことが起きます。次のページは演算子のオーバーロードについての記事です。 https://ufcpp.net/study/csharp/oo_operator.html また、二つのオブジェクトを比較する際の概要を次の記事にまとめていますので、参照してください。 https://qiita.com/Zuishin/items/62c5b726bfa589b3fb9b これに加えて is を使う方法もあり、新しいバージョンの C# では instance is null で正確に判定できます。

退会済みユーザー

2021/10/10 04:46

ご回答ありがとうございます。今回は1570p様のご回答のほうが適切に思えたので、そちらにベストアンサーを付けさせていただきました。 instance is nullで試したところ、existのログが出力されることも確認しました。ゲームオブジェクトを破棄したことを検知したいので、instance == nullで判定したいと判断しました (実際はnullになっていなくても、ゲームオブジェクトが破棄されたかを知りたい場合はinstance == nullが適切と思いました)。

Zuishin

2021/10/10 04:47

しまったお前だったか。

行動規範の内容に同意します