Singleton pattern is the most pervasive pattern in the Spring containerization approach. If we look at that in terms of architectural primitives - they form a blackboard graph of objects, to which every thread can read and write. They do the dramatic act of synchronizing between multiple threads. The very reason why multiple threads need to synchronize is because there are always resources that underlie a computational program, over which contention might occur. Consider what is called a 'last seat problem'. A flight is being booked, but there are multiple ways to do it. For simplicity lets assume that the data about the flight occupancy is stored in a flat file rather than a database. Now, if there are two threads, each functionally different (i.e represented by different endpoints in the webapp) and let one of these threads A, be the thread which a prospective passenger uses to make a booking and the other one B is which a flight manager uses to close the booking - virtually closing the boarding door. Then, if these threads do not use singleton, the flight object would be detached from the real resource out-there, which we say not the actual aeroplane but the entry in the flat file. The A thread would have reference to an object, while the passenger is still fighting a dilemma whether to fly or not and then finally when he makes up his mind, the B thread would already have closed the door. But the object referenced by the A thread would still show one more seat to go. Now, cutting out the RDBMS due to our initial assumption, the system would write a ticket for the passenger and issue it to him eventhough the boarding is closed. Now, in a singleton implementation, the moment the theread B accesses the system, the universal object Flight is updated with status closed. Hence, if the passenger finally makes up his mind and clicks confirm, he would get an error right away. All this would not have been possible without the singleton. Hence, singleton allows you to stay close to the resources and avoids thread contention.

I use it for an object encapsulating command-line parameters when dealing with pluggable modules. The main program doesn't know what the command-line parameters are for modules that get loaded (and doesn't always even know what modules are being loaded). e.g., main loads A, which doesn't need any parameters itself (so why it should take an extra pointer / reference / whatever, I'm not sure - looks like pollution), then loads modules X, Y, and Z. Two of these, say X and Z, need (or accept) parameters, so they call back to the command-line singleton to tell it what parameters to accept, and the at runtime they call back to find out if the user actually has specified any of them.

在很多方面，处理CGI参数的单例方式与你每次查询只使用一个进程类似(其他mod_*方法不这样做，所以这很糟糕——因此这个参数说你不应该在mod_cgi世界中使用单例，以防你移植到mod_perl或其他世界)。

管理到数据库的连接(或连接池)。

我还会使用它来检索和存储外部配置文件中的信息。

共享资源。特别是在PHP中，数据库类、模板类和全局变量库类。所有这些都必须由代码中使用的所有模块/类共享。

这是一个真正的对象使用——>模板类包含正在构建的页面模板，它被添加到页面输出的模块塑造、添加、更改。它必须保持为单个实例，这样才能实现这一点，数据库也是如此。使用共享数据库单例，所有模块的类都可以访问查询，并且无需重新运行查询。

全局变量仓库单例为您提供了一个全局的、可靠的、易于使用的变量仓库。它极大地整理了你的代码。想象一下，所有配置值都在一个单例数组中，如下所示:

美元gb - > problem[’hostname’]

或者将所有的语言值放在一个数组中，比如:

gb - >朗(“ENTER_USER”)

在运行页面代码的最后，你会得到，比如说，一个现在成熟的:

美元的模板

Singleton，一个$gb的Singleton，其中有lang数组用于替换，所有输出都已加载并准备就绪。您只需将它们替换为现在在成熟模板对象的页面值中呈现的键，然后将其提供给用户。

这样做的最大好处是你可以对任何东西做任何你喜欢的后期处理。您可以将所有语言值输送到谷歌translate或其他翻译服务，并将它们返回，并将它们替换到它们的位置，例如，已翻译。或者，您可以根据需要替换页面结构或内容字符串。

也许是一个带有代码的示例。

在这里，ConcreteRegistry是一个纸牌游戏中的单例，它允许行为沿着包树向上访问游戏的少数核心接口(即模型、视图、控制器、环境等的外观):

http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs40.html

Ed.

我不认为Singleton的场景与记录器、打印机池或任何示例相关。

单例决策的目的是优化硬件资源，而不是只有一个地方来控制任何记录器或打印机池

我个人认为单例应该在以下情况下使用:

我们正在谈论的对象总是以相同的方式实例化(即任何共享资源，如Logger或打印机池) 它被多次调用(这可以是100或1000，这与您的资源有关) 你的硬件资源是有限的(例如内存、处理能力等)。

如果你有大量的内存空间和处理能力，我认为没有必要使用单例。

Singleton将确保你只有一个实例，并且是惰性加载的，那么如果它被调用一百万次，你就只创建了一个对象。