我可以说是枚举单例。

在Java中使用枚举通常是声明枚举单例的一种方法。枚举单例可以包含实例变量和实例方法。为了简单起见，还要注意，如果您正在使用任何实例方法，那么如果该方法影响对象的状态，则需要确保该方法的线程安全。

枚举的使用非常容易实现，并且在可序列化对象方面没有缺点，必须通过其他方式规避这些缺点。

/**
* Singleton pattern example using a Java Enum
*/
public enum Singleton {
    INSTANCE;
    public void execute (String arg) {
        // Perform operation here
    }
}

您可以通过Singleton.INSTANCE访问它，它比在Singleton上调用getInstance（）方法简单得多。

1.12枚举常量的序列化枚举常量的序列化方式不同于普通的可序列化或可外部化对象。枚举常量的序列化形式仅由其名称组成；表单中不存在常量的字段值。若要序列化枚举常量，ObjectOutputStream将写入枚举常量的name方法返回的值。要反序列化枚举常量，ObjectInputStream从流中读取常量名称；然后通过调用java.lang.Enum.valueOf方法获得反序列化的常量，并将常量的枚举类型与接收到的常量名称作为参数一起传递。与其他可序列化或可外部化对象一样，枚举常量可以用作后续在序列化流中出现的反向引用的目标。无法自定义枚举常量的序列化过程：在序列化和反序列化期间，将忽略枚举类型定义的任何类特定的writeObject、readObject、readObjectNoData、writeReplace和readResolve方法。类似地，任何serialPersistentFields或serialVersionUID字段声明也会被忽略——所有枚举类型都具有固定的serialVersionID 0L。记录枚举类型的可序列化字段和数据是不必要的，因为发送的数据类型没有变化。引自Oracle文档

传统singleton的另一个问题是，一旦实现了Serializable接口，它们就不再是单一的，因为readObject（）方法总是返回一个新的实例，就像Java中的构造函数一样。这可以通过使用readResolve（）并丢弃新创建的实例来避免，方法是将其替换为单例，如下所示：

 // readResolve to prevent another instance of Singleton
 private Object readResolve(){
     return INSTANCE;
 }

如果您的单例类保持状态，这可能会变得更加复杂，因为您需要使它们成为瞬态的，但是在枚举单例中，JVM保证了序列化。

---

好的阅读

Singleton模式枚举、Singleton和反序列化双重检查锁定和Singleton模式

我对一些答案感到困惑，这些答案建议依赖注入（DI）作为使用单态的替代方案；这些都是不相关的概念。您可以使用DI注入单例或非单例（例如，每个线程）实例。至少如果您使用Spring2.x，这是正确的，我不能为其他DI框架说话。

所以我对OP的回答是（除了最简单的示例代码之外）：

使用类似Spring framework的DI框架，然后将其作为DI配置的一部分，无论依赖项是单体的、请求范围的、会话范围的还是其他。

这种方法为您提供了一个很好的解耦（因此是灵活和可测试的）架构，其中是否使用单例是一个容易可逆的实现细节（当然，前提是您使用的任何单例都是线程安全的）。

创建单例对象的各种方法：

根据约书亚·布洛赫的说法，埃努姆将是最好的。也可以使用双重检查锁定。甚至可以使用内部静态类。

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

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

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

免责声明：我刚刚总结了所有很棒的答案，并用自己的话写了出来。

---

在实施Singleton时，我们有两种选择：

延迟加载早期加载

延迟加载增加了位开销（老实说，很多），所以只有当您有非常大的对象或大量的构造代码，并且有其他可访问的静态方法或字段（可能在需要实例之前使用）时，才需要使用延迟初始化。否则，选择提前加载是一个不错的选择。

实现单例的最简单方法是：

public class Foo {

    // It will be our sole hero
    private static final Foo INSTANCE = new Foo();

    private Foo() {
        if (INSTANCE != null) {
            // SHOUT
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        return INSTANCE;
    }
}

一切都很好，除了它是一个早期加载的单例。让我们尝试延迟加载的单例

class Foo {

    // Our now_null_but_going_to_be sole hero
    private static Foo INSTANCE = null;

    private Foo() {
        if (INSTANCE != null) {
            // SHOUT
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        // Creating only  when required.
        if (INSTANCE == null) {
            INSTANCE = new Foo();
        }
        return INSTANCE;
    }
}

到目前为止还不错，但我们的英雄在与多个邪恶线程单独战斗时将无法生存，这些线程需要我们英雄的许多实例。因此，让我们保护它免受邪恶的多线程攻击：

class Foo {

    private static Foo INSTANCE = null;

    // TODO Add private shouting constructor

    public static Foo getInstance() {
        // No more tension of threads
        synchronized (Foo.class) {
            if (INSTANCE == null) {
                INSTANCE = new Foo();
            }
        }
        return INSTANCE;
    }
}

但这还不足以保护英雄，真的！！！这是我们能/应该做的最好的事情来帮助我们的英雄：

class Foo {

    // Pay attention to volatile
    private static volatile Foo INSTANCE = null;

    // TODO Add private shouting constructor

    public static Foo getInstance() {
        if (INSTANCE == null) { // Check 1
            synchronized (Foo.class) {
                if (INSTANCE == null) { // Check 2
                    INSTANCE = new Foo();
                }
            }
        }
        return INSTANCE;
    }
}

这被称为“双重检查锁定习惯用法”。人们很容易忘记不稳定的说法，也很难理解为什么有必要这样做。详细信息：“双重检查锁定失败”声明

现在我们确定了邪恶的线索，但残酷的连载呢？我们必须确保即使在反序列化时也不会创建新对象：

class Foo implements Serializable {

    private static final long serialVersionUID = 1L;

    private static volatile Foo INSTANCE = null;

    // The rest of the things are same as above

    // No more fear of serialization
    @SuppressWarnings("unused")
    private Object readResolve() {
        return INSTANCE;
    }
}

方法readResolve（）将确保返回唯一的实例，即使对象在我们的程序的上一次运行中被序列化。

最后，我们添加了足够的线程和序列化保护，但我们的代码看起来又大又难看。让我们给我们的英雄一个新形象：

public final class Foo implements Serializable {

    private static final long serialVersionUID = 1L;

    // Wrapped in a inner static class so that loaded only when required
    private static class FooLoader {

        // And no more fear of threads
        private static final Foo INSTANCE = new Foo();
    }

    // TODO add private shouting construcor

    public static Foo getInstance() {
        return FooLoader.INSTANCE;
    }

    // Damn you serialization
    @SuppressWarnings("unused")
    private Foo readResolve() {
        return FooLoader.INSTANCE;
    }
}

是的，这是我们的英雄：）

由于行private static final Foo INSTANCE=new Foo（）；仅在实际使用FooLoader类时执行，这会处理延迟实例化，并保证线程安全。

我们已经走到了今天。以下是实现我们所做一切的最佳方式：

public enum Foo {
    INSTANCE;
}

内部将被视为

public class Foo {

    // It will be our sole hero
    private static final Foo INSTANCE = new Foo();
}

就是这样！不再担心序列化、线程和丑陋的代码。ENUMS单例也被延迟初始化。

该方法在功能上等同于公共领域方法，除了它更简洁，提供了序列化机制免费提供，并提供多重保险实例化，即使面对复杂的序列化或反射攻击。虽然这种方法尚未被广泛采用，单个元素枚举类型是实现单例的最佳方式。

-《有效的Java》中的约书亚·布洛赫

现在您可能已经意识到为什么ENUMS被认为是实现单例的最佳方式，并感谢您的耐心：）

在我的博客上更新了它。

Stu Thompson发布的解决方案在Java 5.0及更高版本中有效。但我宁愿不使用它，因为我认为它容易出错。

人们很容易忘记不稳定的说法，也很难理解为什么有必要这样做。如果没有易失性，由于双重检查锁定反模式，该代码将不再是线程安全的。有关这一点的更多信息，请参阅《Java并发实践》第16.2.4段。简而言之：此模式（在Java5.0之前或没有volatile语句）可能返回对Bar对象的引用，该对象（仍然）处于错误状态。

这种模式是为性能优化而发明的。但这真的不再是一个真正的问题了。下面的惰性初始化代码很快，更重要的是，更容易阅读。

class Bar {
    private static class BarHolder {
        public static Bar bar = new Bar();
    }

    public static Bar getBar() {
        return BarHolder.bar;
    }
}