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或其他世界)。

将特定的基础设施关注点配置为单例或全局变量是非常实用的。我最喜欢的例子是依赖注入框架，它使用单例作为框架的连接点。

在这种情况下，您将依赖于基础设施来简化库的使用并避免不必要的复杂性。

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

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

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

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

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

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

一个实例可以在Test::Builder中找到，这个类支持几乎所有现代Perl测试模块。Builder单例存储并代理测试流程的状态和历史记录(历史测试结果，计算运行的测试次数)以及测试输出流向等内容。这些都是协调由不同作者编写的多个测试模块以在单个测试脚本中一起工作所必需的。

The history of Test::Builder's singleton is educational. Calling new() always gives you the same object. First, all the data was stored as class variables with nothing in the object itself. This worked until I wanted to test Test::Builder with itself. Then I needed two Test::Builder objects, one setup as a dummy, to capture and test its behavior and output, and one to be the real test object. At that point Test::Builder was refactored into a real object. The singleton object was stored as class data, and new() would always return it. create() was added to make a fresh object and enable testing.

Currently, users are wanting to change some behaviors of Test::Builder in their own module, but leave others alone, while the test history remains in common across all testing modules. What's happening now is the monolithic Test::Builder object is being broken down into smaller pieces (history, output, format...) with a Test::Builder instance collecting them together. Now Test::Builder no longer has to be a singleton. Its components, like history, can be. This pushes the inflexible necessity of a singleton down a level. It gives more flexibility to the user to mix-and-match pieces. The smaller singleton objects can now just store data, with their containing objects deciding how to use it. It even allows a non-Test::Builder class to play along by using the Test::Builder history and output singletons.

似乎在数据的协调和行为的灵活性之间存在着一种推拉关系，这种关系可以通过在共享数据周围使用尽可能少的行为来缓解，以确保数据的完整性。

使用单例的方法之一是覆盖一个实例，其中必须有一个“代理”控制对资源的访问。单例在日志记录器中很好，因为它们代理访问，比如说，一个文件，这个文件只能被写入。对于像日志这样的东西，它们提供了一种方法来抽象出对日志文件之类的东西的写操作——你可以将缓存机制包装到你的单例中，等等……

也可以考虑这样一种情况，你有一个应用程序，有许多窗口/线程等，但它需要一个单一的通信点。我曾经使用它来控制我希望应用程序启动的作业。单例程序负责将作业序列化，并将它们的状态显示给程序中其他感兴趣的部分。在这种情况下，你可以把单例对象看作是在应用程序中运行的“服务器”类……HTH