问题标签 [singleton]

基于 SO 问题Best Singleton Implementation In Java - 即关于使用枚举创建单例 - 之间的区别/优点/缺点是什么（省略了构造函数）

然后打电话Elvis.INSTANCE.getAge()

和

然后打电话Elvis.getAge()

我在所有 PHP 类文件中使用单例模式。

是否会导致用户在网站上的操作与其他用户的操作发生冲突？

例如，当应用程序上线并且我们同时在站点上有几个用户时，做类似的事情，从而调用相同的 PHP 类（在幕后），因为单例阻止了一个类的多个实例并且只返回一个实例.

例如，我有一个名为 Search.php 的类，它是一个单例类。此类处理来自网站的所有搜索查询。如果多个用户同时在站点上执行搜索，他们的操作是否会相互冲突，因为它只是可以创建的 Search 类的单个实例。

非常感谢你花时间陪伴。

我无法让单例模式在 smalltalk 中初始化实例变量。（这里是另一个实现的链接以进行澄清）

这就是我所拥有的：

最后一行 (UniqueInstance: instanceVar := Object new.) 不起作用，但这基本上就是我需要做的：在将 UniqueInstance 返回给调用者之前将 instanceVar 实例化为对象。

请注意，此“新”方法用作类实例化，并且库是 UniqueIsntance（所需类的实例）的实例变量。

谁能指出我正确的方向？

DAL (customerDAL) 中的类不应该是单例的吗？由于我的控制器 (customerController) 公开了“Shared Subs”，因此在每次调用时，如果已经存在，则无需创建新的 DAL 对象。正确的？

谢谢

我正在寻找一段代码，它的行为有点像单例但不是（因为单例很糟糕:) 我正在寻找的必须满足这些目标：

1. 线程安全
2. 简单（理解和使用，即几行代码。库调用是可以的）
3. 快速地
4. 不是单身；对于测试，必须可以覆盖该值（并在测试后将其重置）。
5. 本地（所有必要信息必须在一个地方）
6. 惰性（仅在实际需要该值时运行）。
7. 运行一次（RHS 上的代码必须执行一次且仅一次）

示例代码：

请注意，这些字段不是静态的；只有表达式的 RHS（右手边）是……在某种程度上是“静态的”。测试应该能够临时注入新i值greet。

另请注意，这段代码概述了我打算如何使用这个新代码。随意用任何东西替换 runOnce() 或将其移动到其他地方（构造函数，也许，或 init() 方法或 getter）。但是 LOC 越少越好。

一些背景资料：

我不是在寻找 Spring，而是在寻找一段可用于最常见情况的代码：您需要实现一个接口，除了您想要的测试之外，永远不会有第二个实现传入模拟对象。此外，Spring 失败了 #2、#3 和 #5：您需要学习配置语言，您必须在某处设置应用程序上下文，它需要 XML 解析器并且它不是本地的（信息遍布各处）。

由于#5，全局配置对象或工厂不符合要求。

static final因为#4而出局（不能改变决赛）。static由于类加载器问题而有异味，但您可能需要在里面使用它runOnce()。我只是希望能够在表达式的 LHS 中避免它。

一种可能的解决方案可能是将ehcache与默认设置一起使用，该设置将返回相同的对象。由于我可以将内容放入缓存中，因此这也允许随时覆盖该值。但也许有比 ehcache 更紧凑/简单的解决方案（它再次需要 XML 配置文件等）。

[编辑] 我想知道为什么这么多人不赞成这个。这是一个有效的问题，用例很常见（至少在我的代码中）。因此，如果您不理解问题（或其背后的原因），或者您没有答案或不在乎，为什么要投反对票？：/

[EDIT2] 如果您查看 Spring 的应用程序上下文，您会发现超过 99% 的所有 bean 都只有一个实现。你可以拥有更多，但在实践中，你根本没有。因此，我没有分离接口、实现和配置，而是在寻找只有一个实现（在最简单的情况下）、一个 current() 方法和一两行聪明的代码来初始化 current() 的结果的东西一次（第一次调用时）但同时允许覆盖结果（如果可能，线程安全）。把它想象成一个原子的“if(o==null) o = new O(); return o”，你可以在其中覆盖 o。也许 AtomicRunOnceReference 类是解决方案。

现在，我只是觉得我们每天都拥有和使用的并不是最佳的，有一个莫名其妙的解决方案会让我们都拍脑袋说“就是这样”。就像我们几年前 Spring 出现时的感觉一样，我们意识到我们所有的单例问题来自哪里以及如何解决它们。

在 .NET 3.5 中，我想创建一个单例接口：

当然这不起作用，但这是我想要的。有什么建议么？

编辑：我只想知道所有的单例都会有一个名为 Instance 的类类型的静态属性。它总是在那里。接口将是表达这一点的明确方式。

在 C++ 中实现单例时，GetInstance() 是返回指向单例对象的指针还是引用更好？真的有关系吗？

我已经看到了单例模式的实现，其中实例变量在 GetInstance 方法中被声明为静态变量。像这样：

我看到了这种方法的以下积极方面：

• 代码更简单，因为只有在第一次调用 GetInstance 时，编译器才负责创建这个对象。
• 代码更安全，因为没有其他方法可以获取对实例的引用，而是使用 GetInstance 方法，并且没有其他方法可以更改实例，而是在 GetInstance 方法中。

这种方法有哪些负面影响（除了这不是非常面向 OOP 的）？这是线程安全的吗？

这个网站上有很多关于为什么应该避免单例的讨论，但是在任何情况下单例是有意义的并且是最好的选择吗？

我认为单例是最佳选择的一个例子是在实现身份映射时，您需要跟踪已经从映射层中的数据库加载的所有模型。在这种情况下，重要的是映射实际上是全局的，以便所有客户端代码使用映射的相同实例并且它们都访问相同的加载模型列表。最简单的解决方案似乎是将类实现为单例（或静态方法）。这是最好的方法还是有其他方法？

是否还有其他情况可以使用单例，或者它们总是不好？

这是我从“CLR via C#”、“Effective C#”和其他资源中对 IDisposable 和终结器的理解：

• IDisposable 用于确定性地清理托管和非托管资源。
• 负责非托管资源（例如文件句柄）的类应实现 IDisposable 并提供终结器以确保即使客户端代码未在实例上调用 Dispose() 也能清理它们。
• 只负责托管资源的类不应该实现终结器。
• 如果你有一个终结器，那么你必须实现 IDisposable（这允许客户端代码做正确的事情并调用 Dispose()，而终结器可以防止在他们忘记时泄漏资源）。

虽然我理解并同意上述所有内容，但在一种情况下，我认为打破这些规则是有意义的：一个负责非托管资源的单例类（例如提供对特定文件的单点访问） ）。

我认为在单例上使用 Dispose() 方法总是错误的，因为单例实例应该在应用程序的整个生命周期内都存在，如果有任何客户端代码调用 Dispose() 那么你就被塞满了。但是，您需要一个终结器，以便在卸载应用程序时终结器可以清理非托管资源。

因此，在我看来，拥有一个带有不实现 IDisposable 的终结器的单例类似乎是一件合理的事情，但这种类型的设计与我所理解的最佳实践背道而驰。

这是一个合理的方法吗？如果不是，为什么不呢？有什么更好的选择？