在Java中实现单例设计模式的有效方法是什么?
当前回答
我见过的最好的单例模式使用Supplier接口。
它是通用的,可重复使用它支持延迟初始化它只有在初始化之前才同步,然后将阻塞供应商替换为非阻塞供应商。
见下文:
public class Singleton<T> implements Supplier<T> {
private boolean initialized;
private Supplier<T> singletonSupplier;
public Singleton(T singletonValue) {
this.singletonSupplier = () -> singletonValue;
}
public Singleton(Supplier<T> supplier) {
this.singletonSupplier = () -> {
// The initial supplier is temporary; it will be replaced after initialization
synchronized (supplier) {
if (!initialized) {
T singletonValue = supplier.get();
// Now that the singleton value has been initialized,
// replace the blocking supplier with a non-blocking supplier
singletonSupplier = () -> singletonValue;
initialized = true;
}
return singletonSupplier.get();
}
};
}
@Override
public T get() {
return singletonSupplier.get();
}
}
其他回答
实现单例有很多细微差别。夹持器图案不能在许多情况下使用。在使用volatile时,也应该使用局部变量。让我们从头开始,反复讨论这个问题。你会明白我的意思的。
第一次尝试可能看起来像这样:
public class MySingleton {
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new MySingleton();
}
return INSTANCE;
}
...
}
这里我们有一个MySingleton类,它有一个名为INSTANCE的私有静态成员和名为getInstance()的公共静态方法。第一次调用getInstance()时,INSTANCE成员为空。然后,流将进入创建条件,并创建MySingleton类的新实例。对getInstance()的后续调用将发现INSTANCE变量已设置,因此不会创建另一个MySingleton实例。这确保只有一个MySingleton实例在getInstance()的所有调用方之间共享。
但这种实现有一个问题。多线程应用程序在创建单个实例时具有竞争条件。如果多个执行线程同时(或前后)命中getInstance()方法,它们将分别将INSTANCE成员视为null。这将导致每个线程创建一个新的MySingleton实例,然后设置instance成员。
private static MySingleton INSTANCE;
public static synchronized MySingleton getInstance() {
if (INSTANCE == null) {
INSTANCE = new MySingleton();
}
return INSTANCE;
}
这里我们在方法签名中使用了synchronized关键字来同步getInstance()方法。这肯定会修复我们的种族状况。线程现在将一次一个地阻塞并进入方法。但这也造成了性能问题。这个实现不仅同步了单个实例的创建;它同步对getInstance()的所有调用,包括读取。读取不需要同步,因为它们只需返回INSTANCE的值。由于读取将构成我们调用的大部分(记住,实例化只发生在第一次调用上),因此通过同步整个方法,我们将导致不必要的性能损失。
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronize(MySingleton.class) {
INSTANCE = new MySingleton();
}
}
return INSTANCE;
}
在这里,我们将同步从方法签名移到了一个同步块,该块包装MySingleton实例的创建。但这能解决我们的问题吗?嗯,我们不再阻止读取,但我们也后退了一步。多个线程将同时或几乎同时命中getInstance()方法,它们都会将INSTANCE成员视为空。
然后,它们将到达同步块,在那里将获得锁并创建实例。当该线程退出块时,其他线程将争夺锁,每个线程将逐一通过块并创建我们类的新实例。所以我们回到了我们开始的地方。
private static MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronized(MySingleton.class) {
if (INSTANCE == null) {
INSTANCE = createInstance();
}
}
}
return INSTANCE;
}
在这里,我们从区块内部发出另一张支票。如果INSTANCE成员已经设置,我们将跳过初始化。这称为双重检查锁定。
这解决了我们的多重实例化问题。但我们的解决方案再次提出了另一个挑战。其他线程可能无法“看到”INSTANCE成员已更新。这是因为Java如何优化内存操作。
线程将变量的原始值从主内存复制到CPU的缓存中。然后,对值的更改将写入该缓存并从中读取。这是Java的一个旨在优化性能的特性。但这给我们的单例实现带来了一个问题。第二个线程 — 由不同的CPU或内核使用不同的缓存进行处理 — 不会看到第一个所做的更改。这将导致第二个线程将INSTANCE成员视为空,从而强制创建单例的新实例。
private static volatile MySingleton INSTANCE;
public static MySingleton getInstance() {
if (INSTANCE == null) {
synchronized(MySingleton.class) {
if (INSTANCE == null) {
INSTANCE = createInstance();
}
}
}
return INSTANCE;
}
我们通过在INSTANCE成员的声明上使用volatile关键字来解决这个问题。这将告诉编译器始终读取和写入主内存,而不是CPU缓存。
但这种简单的改变是有代价的。因为我们绕过了CPU缓存,所以每次对易失性INSTANCE成员进行操作时,我们都会受到性能影响 — 我们做了四次。我们再次检查存在性(1和2),设置值(3),然后返回值(4)。有人可能会说,这条路径是边缘情况,因为我们只在方法的第一次调用期间创建实例。也许创作上的表现是可以容忍的。但即使是我们的主要用例reads,也会对volatile成员进行两次操作。一次检查是否存在,再次返回其值。
private static volatile MySingleton INSTANCE;
public static MySingleton getInstance() {
MySingleton result = INSTANCE;
if (result == null) {
synchronized(MySingleton.class) {
result = INSTANCE;
if (result == null) {
INSTANCE = result = createInstance();
}
}
}
return result;
}
由于性能受到影响是由于直接对volatile成员进行操作,所以让我们将一个局部变量设置为volatile的值,并改为对局部变量进行操作。这将减少我们在易失性上操作的次数,从而收回一些损失的性能。注意,当我们进入同步块时,必须再次设置本地变量。这确保了它是最新的,以及在我们等待锁时发生的任何更改。
我最近写了一篇关于这个的文章。解构单身汉。您可以在那里找到有关这些示例和“持有者”模式示例的更多信息。还有一个真实的例子展示了双重检查的易失性方法。
我使用Spring框架来管理我的单件。
它并没有强制实现类的“单例性”(如果涉及多个类加载器,则无论如何都无法做到这一点),但它提供了一种非常简单的方法来构建和配置不同的工厂以创建不同类型的对象。
忘记延迟初始化;这太有问题了。这是最简单的解决方案:
public class A {
private static final A INSTANCE = new A();
private A() {}
public static A getInstance() {
return INSTANCE;
}
}
另一个经常用来反对单态的论点是它们的可测试性问题。出于测试目的,单体不容易被模拟。如果这是一个问题,我想做以下轻微修改:
public class SingletonImpl {
private static SingletonImpl instance;
public static SingletonImpl getInstance() {
if (instance == null) {
instance = new SingletonImpl();
}
return instance;
}
public static void setInstance(SingletonImpl impl) {
instance = impl;
}
public void a() {
System.out.println("Default Method");
}
}
添加的setInstance方法允许在测试期间设置单例类的实体模型实现:
public class SingletonMock extends SingletonImpl {
@Override
public void a() {
System.out.println("Mock Method");
}
}
这也适用于早期初始化方法:
public class SingletonImpl {
private static final SingletonImpl instance = new SingletonImpl();
private static SingletonImpl alt;
public static void setInstance(SingletonImpl inst) {
alt = inst;
}
public static SingletonImpl getInstance() {
if (alt != null) {
return alt;
}
return instance;
}
public void a() {
System.out.println("Default Method");
}
}
public class SingletonMock extends SingletonImpl {
@Override
public void a() {
System.out.println("Mock Method");
}
}
这有一个缺点,就是将此功能也暴露给普通应用程序。其他编写该代码的开发人员可能会尝试使用“setInstance”方法来更改特定函数,从而改变整个应用程序的行为,因此该方法的javadoc中至少应该包含一个良好的警告。
尽管如此,对于模型测试的可能性(当需要时),这种代码暴露可能是可以接受的代价。
有时简单的“static Foo=new Foo();”是不够的。想想你想做的一些基本数据插入。
另一方面,您必须同步任何实例化单例变量的方法。同步本身并不坏,但它可能会导致性能问题或锁定(在非常罕见的情况下,使用本示例。解决方案是
public class Singleton {
private static Singleton instance = null;
static {
instance = new Singleton();
// do some of your instantiation stuff here
}
private Singleton() {
if(instance!=null) {
throw new ErrorYouWant("Singleton double-instantiation, should never happen!");
}
}
public static getSingleton() {
return instance;
}
}
现在会发生什么?类通过类加载器加载。在从字节数组解释类之后,VM立即执行静态{}-块。这就是全部秘密:静态块只被调用一次,即这个单类加载器加载给定包的给定类(名称)的时间。
推荐文章
- 在流中使用Java 8 foreach循环移动到下一项
- 访问限制:'Application'类型不是API(必需库rt.jar的限制)
- 用Java计算两个日期之间的天数
- 如何配置slf4j-simple
- 在Jar文件中运行类
- 带参数的可运行?
- 我如何得到一个字符串的前n个字符而不检查大小或出界?
- 我可以在Java中设置enum起始值吗?
- Java中的回调函数
- c#和Java中的泛型有什么不同?和模板在c++ ?
- 在Java中,流相对于循环的优势是什么?
- Jersey在未找到InjectionManagerFactory时停止工作
- 在Java流是peek真的只是调试?
- Recyclerview不调用onCreateViewHolder
- 将JSON字符串转换为HashMap