Another problem that comes with using GameObject Singletons is "scene ownership". Your singleton lives in a particular scene, and every time you want to test another scene in isolation that has references to that singleton, it's a pain in the butt. Basically you need to add all the "Managers" and global instances in order to have a working scene.

I found myself using less and less the singleton pattern for this exact reason. Lately I've been switching to ScriptableObjects to hold global state. The neat thing is you can make them as singletons too! if you want! But this time, if you put them in a Resources folder and load them from here, you can access them everywhere, every-time, without the need of a scene instance.

I know that this video is about a year old or more.  But even at that time, Unity wasn't exclusively a single-threaded engine.  As soon as you step into the realm of the Scriptable Render Pipeline, which the HDRP and URP are members of, You then start to see Unity relying more on the burst compiler and the creation of multithreaded jobs.  Even though Unity does a good job at protecting the user, there are still conditions where these patterns could be an issue.  Especially if you start using the job system yourself.

Very solid work! ServiceLocator is an underutilized technique (compared to pure Singletons).

Very High Quality explanations, you deserve much more audience. I found it super super useful, thank you very much.
I suggest you to make more video like this, in which you could give us some other advices about design pattern or good programming practices, because I think you have very good teaching qualities

Man what a good video, damn. Loved it!

Really like how you've gone into the details on this. Never thought of SerializeField references being problematic when more than one person is working on a project. Service Locators are a new pattern for me too. Seems useful but is it actually different to just using FindObjectOfType, which is known to be super slow ?  (apart from the caching you're doing) My main fear with it is that you're not forcing a single instance of these 'Services' which seems like a recipe for disaster (especially in the context of more than one programmer working on a project)
You have a great knack of clearly explaining deep programming concepts, I'd love to see you do a video on Dependency Injection. Had a quick Google but it all seemed a bit over my head. :)

Thank you for the great explenation. Now at least I know the name of something I´ve been using the whole time and even funnier, I thought I invented this pattern  XD Thank you sir for your time and efforts :)

I hear "Singleton bad" everywhere but I don't hear anyone giving a clear answer as to why

I've changed this into a static class that has a Register<T> method for my main systems (AudioSystem, SaveSystem etc) to register themselves and I get references on Start() at my custom scripts

What is the reason for the two Equals() in the null check in your singleton implementation? I'm pretty sure "_instance==null" would've sufficed. :)

Very good video! Could using a service locator with asynchronous methods lead to race conditions?

Not a big fan of the explanation. Doesn't clarify why a bunch of Singletons is worse than the Service Locator pattern. Yes, Singletons are globally accessible which is bad but this is the case with both patterns so...