使用雙重檢查鎖定實(shí)現(xiàn)懶加載單例時(shí)，需用volatile關(guān)鍵字確保線程可見(jiàn)性並防止指令重排；2. 推薦使用靜態(tài)內(nèi)部類（Bill Pugh方案）實(shí)現(xiàn)線程安全的懶加載單例，因JVM保證類初始化的線程安全性且無(wú)同步開(kāi)銷(xiāo)；3. 若無(wú)需懶加載，可採(cǎi)用靜態(tài)常量方式實(shí)現(xiàn)簡(jiǎn)單高效的餓漢式單例；4. 當(dāng)涉及序列化時(shí)，應(yīng)使用枚舉方式，因其能天然防止反射和序列化導(dǎo)致的多實(shí)例問(wèn)題；綜上，一般場(chǎng)景優(yōu)先選擇靜態(tài)內(nèi)部類，序列化場(chǎng)景選擇枚舉，二者均具備線程安全、高性能和代碼簡(jiǎn)潔的優(yōu)點(diǎn)。

Implementing a thread-safe singleton in Java is a common requirement in multi-threaded applications where you want to ensure that only one instance of a class exists and that it's safely accessible across multiple threads. Here's how to do it properly using different approaches, each with its own trade-offs.

1. Lazy Initialization with Double-Checked Locking

This approach creates the instance only when needed (lazy loading) and ensures thread safety with minimal performance overhead after the first creation.

 public class Singleton {
    // Volatile ensures visibility across threads
    private static volatile Singleton instance;

    private Singleton() {
        // Prevent instantiation via reflection
        if (instance != null) {
            throw new RuntimeException("Use getInstance() method to create instance.");
        }
    }

    public static Singleton getInstance() {
        if (instance == null) { // First check (no lock)
            synchronized (Singleton.class) {
                if (instance == null) { // Second check (with lock)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Key Points:

• volatile keyword prevents instruction reordering and ensures that changes to instance are immediately visible to all threads.
• The first null check avoids synchronization after the instance is created.
• Double-checked locking reduces the overhead of acquiring a lock every time getInstance() is called.

?? Without volatile , this pattern can fail due to memory model issues — one thread might see a partially constructed object.

2. Static Inner Class (Bill Pugh Solution)

This is the most widely recommended approach for lazy, thread-safe singletons without synchronization overhead.

 public class Singleton {
    private Singleton() {
        if (InstanceHolder.INSTANCE != null) {
            throw new RuntimeException("Use getInstance() method.");
        }
    }

    public static Singleton getInstance() {
        return InstanceHolder.INSTANCE;
    }

    // Inner static class is not loaded until referenced
    private static class InstanceHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

Why it works:

• The inner class InstanceHolder is loaded only when getInstance() is called.
• JVM guarantees that class initialization is thread-safe.
• No need for synchronized or volatile .
• Lazy loading is achieved naturally.

? This is clean, efficient, and recommended for most use cases.

3. Eager Initialization (Simple but Not Lazy)

If you don't need lazy loading, this is the simplest and thread-safe way.

 public class Singleton {
    private static final Singleton INSTANCE = new Singleton();

    private Singleton() {}

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

Pros:

• Simple and inherently thread-safe.
• No synchronization needed.

Cons:

• Instance is created at class loading time, even if never used.

Use this only if the cost of instantiation is low or guaranteed to be used.

4. Using Enum (Best for Serialization Safety)

Joshua Bloch in Effective Java recommends this approach, especially if serialization is involved.

 public enum Singleton {
    INSTANCE;

    public void doSomething() {
        // Your method logic
    }
}

Advantages:

• Automatically thread-safe.
• Prevents multiple instantiation via reflection, serialization, or deserialization.
• Very concise.

Use case: When you want to be 100% safe from multiple instances in complex environments (eg, with serialization or reflection).

Common Pitfalls to Avoid

• ? Basic lazy initialization without synchronization :

   public static Singleton getInstance() {
      if (instance == null) {
          instance = new Singleton(); // Not thread-safe!
      }
      return instance;
  }

  This can result in multiple instances if two threads enter the block simultaneously.

• ? Synchronizing the whole method (inefficient):

   public static synchronized Singleton getInstance() {
      if (instance == null) {
          instance = new Singleton();
      }
      return instance;
  }

  This works but causes performance bottlenecks — synchronization is needed only once.

  ---

  Final Recommendations

  Use Case	Recommended Approach
  General-purpose lazy singleton	Static inner class
  Serialization involved	Enum singleton
  Simple, early initialization	Eager initialization
  Need fine-grained control (rare)	Double-checked locking

  ---

  Basically, use the static inner class approach unless you're dealing with serialization — then go with enum . Both are thread-safe, clean, and performant.

  以上是在Java中實(shí)現(xiàn)線程安全單例的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！