public class Singleton {

    private static final Singleton INSTANCE = new Singleton();

    private Singleton() {
        if (INSTANCE != null)
            throw new IllegalStateException(“Already instantiated...”);
        }


    public synchronized static Singleton getInstance() {
        return INSTANCE;
    }

}

由于我们在getInstance之前添加了Synchronized关键字，因此在两个线程同时调用getInstance的情况下，我们避免了竞争条件。

在写它之前，真的要考虑一下为什么你需要一个单例。关于使用它们有一个准宗教的争论，如果你在Java中搜索单例，你很容易就会发现。

就我个人而言，出于许多原因，我尽量避免单身汉，其中大部分可以通过谷歌搜索单身汉找到。我觉得单身汉经常被虐待，因为他们很容易被每个人理解。它们被用作将“全局”数据引入OO设计的机制，因为它很容易绕过对象生命周期管理（或者真正思考如何从B内部实现a）。看看像控制反转（IoC）或依赖注入（DI）这样的事情，可以找到一个不错的中间地带。

如果你真的需要一个，那么Wikipedia有一个很好的例子来说明单例的正确实现。

这是如何实现一个简单的单例：

public class Singleton {
    // It must be static and final to prevent later modification
    private static final Singleton INSTANCE = new Singleton();
    /** The constructor must be private to prevent external instantiation */
    private Singleton(){}
    /** The public static method allowing to get the instance */
    public static Singleton getInstance() {
        return INSTANCE;
    }
}

这是如何正确地延迟创建单例：

public class Singleton {
    // The constructor must be private to prevent external instantiation
    private Singleton(){}
    /** The public static method allowing to get the instance */
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
    /**
     * The static inner class responsible for creating your instance only on demand,
     * because the static fields of a class are only initialized when the class
     * is explicitly called and a class initialization is synchronized such that only
     * one thread can perform it, this rule is also applicable to inner static class
     * So here INSTANCE will be created only when SingletonHolder.INSTANCE
     * will be called
     */
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

如果需要惰性地加载类的实例变量，则需要双重检查习惯用法。如果需要惰性地加载静态变量或单例，则需要按需初始化持有者习惯用法。

此外，如果单例需要可序列化，则所有其他字段都需要是暂时的，并且需要实现readResolve（）方法以保持单例对象不变。否则，每次反序列化对象时，都会创建对象的新实例。readResolve（）所做的是用readObject（）替换读取的新对象，因为没有变量引用该对象，所以强制对该新对象进行垃圾回收。

public static final INSTANCE == ....
private Object readResolve() {
  return INSTANCE; // Original singleton instance.
} 

使用枚举：

public enum Foo {
    INSTANCE;
}

乔舒亚·布洛赫（Joshua Bloch）在Google I/O 2008的“有效Java重载”演讲中解释了这种方法：视频链接。另请参见其演示文稿的幻灯片30-32（effecte_java_reloaded.pdf）：

实现可串行化Singleton的正确方法公共枚举Elvis{实例；private final String[]收藏夹歌曲={“猎犬”，“心碎酒店”}；public void printFavorites（）{System.out.println（Arrays.toString（收藏夹歌曲））；}}

编辑：“有效Java”的在线部分说：

“这种方法在功能上等同于公共字段方法，只是它更加简洁，免费提供了序列化机制，并且即使在复杂的序列化或反射攻击的情况下也能提供针对多个实例化的铁腕保证。虽然这种方法尚未被广泛采用，但单个元素枚举类型是实现一个公共字段的最佳方式。”英格顿。"

另一个经常用来反对单态的论点是它们的可测试性问题。出于测试目的，单体不容易被模拟。如果这是一个问题，我想做以下轻微修改：

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中至少应该包含一个良好的警告。

尽管如此，对于模型测试的可能性（当需要时），这种代码暴露可能是可以接受的代价。