2. 程式人生 > >單例模式之執行緒安全解析

單例模式之執行緒安全解析

阿新 • • 發佈：2019-01-01
面試的時候，常常會被問到這樣一個問題：請您寫出一個單例模式（Singleton Pattern）吧。 
    單例的目的是為了保證執行時Singleton類只有唯一的一個例項，最常用的地方比如拿到資料庫的連線，Spring的中建立BeanFactory這些開銷比較大的操作，而這些操作都是呼叫他們的方法來執行某個特定的動作。 
    很容易，順手寫一個《Java與模式》中的第一個例子： 
Java程式碼  收藏程式碼
  1. public final class Singleton {  
  2.     private static Singleton instance = new Singleton();  
  3.     private
     Singleton() {}  
  4.     public static Singleton getInstance() {  
  5.         return instance;  
  6.     }  
  7. }    

    這種寫法就是所謂的餓漢式，每個物件在沒有使用之前就已經初始化了。 
    問題來了，問題1：單例會帶來什麼問題？如果這個物件很大呢？沒有使用這個物件之前，就把它載入到了記憶體中去是一種巨大的浪費。 
    針對這種情況，我們可以對以上的程式碼進行改進，使用一種新的設計思想——延遲載入（Lazy-load Singleton）。 
Java程式碼  收藏程式碼
  1. public final
     class Singleton{    
  2.     private static Singleton instance = null;  
  3.     private Singleton(){}    
  4.     public static Singleton getInstance(){    
  5.         if(instance == null){  
  6.             instance = new Singleton();  
  7.         }   
  8.         return instance;  
  9.     }    
  10. }   

    這種寫法就是所謂的懶漢式。它使用了延遲載入來保證物件在沒有使用之前，是不會進行初始化的。 

    通常這個時候面試官又會提問新的問題來刁難一下。他會問：這種寫法執行緒安全嗎？回答必然是：不安全。 
    這是因為在多個執行緒可能同時執行到第九行，判斷instance為null，於是同時進行了初始化，出現建立多個例項的情況。 
    實際上使用什麼樣的單例實現取決於不同的生產環境，懶漢式適合於單執行緒程式，多執行緒情況下需要保護getInstance()方法，否則可能會產生多個Singleton物件的例項。    
    所以，這是面臨的問題是如何使得這個程式碼執行緒安全？很簡單，在getInstance()方法前面加一個synchronized關鍵字，鎖定整個方法就OK了。 
Java程式碼  收藏程式碼
  1. public final class Singleton{     
  2.     private static Singleton instance=null;     
  3.     private Singleton(){}     
  4.     public static synchronized Singleton getInstance(){     
  5.         if(instance==null){     
  6.              instance=new Singleton();     
  7.          }     
  8.         return instance;     
  9.      }     
  10. }     

    寫到這裡，面試官可能仍然會狡猾的看了你一眼，繼續刁難到：這個寫法有沒有什麼效能問題呢？答案肯定是有的！同步的代價必然會一定程度的使程式的併發度降低。
    鎖定整個方法的是比較耗費資源的，程式碼中實際會產生多執行緒訪問問題的只有 Java程式碼  收藏程式碼
  1. instance = new Singleton();  

    為了降低 synchronized 塊效能方面的影響，把同步的粒度降低，只在初始化物件的時候進行同步，故只鎖定初始化物件語句即可。 
Java程式碼  收藏程式碼
  1. public final Singleton getInstance(){        
  2.     if(instance == null){        
  3.          synchronize(this){           
  4.             instance =  new Singleton();             
  5.          }        
  6.      }        
  7.     return instance;     
  8. }      

    分析這種實現方式，兩個執行緒可以併發地進入第一次判斷instance是否為空的if 語句內部，第一個執行緒執行new操作，第二個執行緒阻斷，當第一個執行緒執行完畢之後，第二個執行緒沒有進行判斷就直接進行new操作，所以這樣做也並不是安全的。 
    為了避免第二次進入synchronized塊沒有進行非空判斷的情況發生，新增第二次條件判斷，即一種新的設計思想——雙重檢查鎖（Double-Checked Lock）。 
Java程式碼  收藏程式碼
  1. public final class Singleton{     
  2.     private static Singleton instance=null;     
  3.     private Singleton(){}     
  4.     public static Singleton getInstance(){        
  5.       if(instance == null){        
  6.          synchronize(this){        
  7.            if(instance == null){        
  8.                instance =  new Singleton();         
  9.             }        
  10.          }        
  11.       }        
  12.       return instance;     
  13.     }       
  14. }     

    這種寫法使得只有在載入新的物件進行同步，在載入完了之後，其他執行緒在第5行就可以判斷跳過鎖的的代價直接到第12行程式碼了。做到很好的併發度。 
    至此，上面的寫法一方面實現了Lazy-Load，另一個方面也做到了併發度很好的執行緒安全，一切看上很完美。 
    但是二次檢查自身會存在比較隱蔽的問題，查了Peter Haggar在DeveloperWorks上的一篇文章，對二次檢查的解釋非常的詳細： 
“雙重檢查鎖定背後的理論是完美的。不幸地是，現實完全不同。雙重檢查鎖定的問題是：並不能保證它會在單處理器或多處理器計算機上順利執行。雙重檢查鎖定失敗的問題並不歸咎於 JVM 中的實現 bug，而是歸咎於 Java 平臺記憶體模型。記憶體模型允許所謂的“無序寫入”，這也是這些習語失敗的一個主要原因。” 
    使用二次檢查的方法也不是完全安全的，原因是 java 平臺記憶體模型中允許所謂的“無序寫入”會導致二次檢查失敗，所以使用二次檢查的想法也行不通了。 
    Peter Haggar在最後提出這樣的觀點：“無論以何種形式，都不應使用雙重檢查鎖定，因為您不能保證它在任何 JVM 實現上都能順利執行。” 
    問題在哪裡？ 
    假設執行緒A執行到了第5行，它判斷物件為空，於是執行緒A執行到第8行去初始化這個物件，但初始化是需要耗費時間的，但是這個物件的地址其實已經存在了。此時執行緒B也執行到了第5行，它判斷不為空，於是直接跳到12行得到了這個物件。但是，這個物件還沒有被完整的初始化！得到一個沒有初始化完全的物件有什麼用！！ 
    關於這個Double-Checked Lock的討論有很多，目前公認這是一個Anti-Pattern，不推薦使用！ 
    那麼有沒有什麼更好的寫法呢？ 
    有！這裡又要提出一種新的模式——Initialization on Demand Holder. 這種方法使用內部類來做到延遲載入物件，在初始化這個內部類的時候，JLS(Java Language Sepcification)會保證這個類的執行緒安全。這種寫法最大的美在於，完全使用了Java虛擬機器的機制進行同步保證，沒有一個同步的關鍵字。 
Java程式碼  收藏程式碼
  1. public class ResourceFactory{  
  2.     private static class ResourceHolder{  
  3.         public static Resource resource = new Resource();        
  4.     }       
  5.     public static Resource getResource() {  
  6.         return ResourceFactory.ResourceHolder.resource;        
  7.     }  
  8. }     

    上面的方式是值得借鑑的，在ResourceFactory中加入了一個私有靜態內部類ResourceHolder ，對外提供的介面是 getResource()方法，也就是隻有在ResourceFactory .getResource()的時候，Resource物件才會被建立， 
    這種寫法的巧妙之處在於ResourceFactory 在使用的時候ResourceHolder 會被初始化，但是ResourceHolder 裡面的resource並沒有被建立， 
    這裡隱含了一個是static關鍵字的用法，使用static關鍵字修飾的變數只有在第一次使用的時候才會被初始化，而且一個類裡面static的成員變數只會有一份，這樣就保證了無論多少個執行緒同時訪問，所拿到的Resource物件都是同一個。 
    值得注意的是，餓漢式的實現方式雖然貌似開銷比較大，但是不會出現執行緒安全的問題，也是解決執行緒安全的單例實現的有效方式。 
    所以本文提出的第一個例子（也是《Java與模式》中的例子），也是使用單例模式的有效方法之一。這種方式沒有使用同步，並且確保了呼叫static getInstance()方法時才建立Singleton的引用（static 的成員變數在一個類中只有一份）。 
    附： 
    餓漢式單例類可以在Java語言實現，但不易在C++內實現，因為靜態初始化在C++裡沒有固定的順序，因而靜態的instance變數的初始化與類的載入順序沒有保證，可能會出問題。這就是為什麼GoF在提出單例類的概念時，舉的例子是懶漢式的。他們的書影響之大，以致Java語言中單例類的例子也大多是懶漢式的。實際上，本書認為餓漢式單例類更符合Java語言本身的特點。 

                                                         ——《Java與模式》作者 

相關推薦

單例模式之執行緒安全解析

面試的時候，常常會被問到這樣一個問題：請您寫出一個單例模式（Singleton Pattern）吧。     單例的目的是為了保證執行時Singleton類只有唯一的一個例項，最常用的地方比如拿到資料庫的連線，Spring的中建立BeanFactory這些開銷比較大的操作，

java 單例模式之執行緒安全的餓漢模式和懶漢模式

單例模式 解決的問題:保證一個類在記憶體中的物件唯一性. 比如：多程式讀取一個配置檔案時，建議配置檔案封裝成物件。會方便操作其中資料，又要保證多個程式讀到的是同一個配置檔案物件， 就需要該配置檔案物件在記憶體中是唯一的。 如何保證物件唯一性呢？ 思想： 1，不讓其他程式建立

設計模式之單例模式（執行緒安全）

可以說單例模式是所有設計模式中最簡單的一種。 單例模式就是說系統中對於某類的只能有一個物件，不可能出來第二個 單例模式也是23種設計模式中在面試時少數幾個會要求寫程式碼的模式之一。主要考察的是多執行緒下面單例模式的執行緒安全性問題。 1.多執行緒安全單例模式例項

設計模式之單例模式與執行緒安全問題

前言 單例模式分為“餓漢模式”與“懶漢模式”。今天我們來聊聊單例模式，特別是在多執行緒中我們需要特別注意。 餓漢模式 class Singleton{ private static Singleton singleton = new Singleton(); private Singl

python中單例模式的執行緒安全問題

看了好多文章都是java實現的，特此寫一篇python的。 這個問題的兩種解決方案： 1.最簡單粗暴的就是在系統中先生成一個單例，就不存線上程安全問題了 2.用雙重同步鎖去實現，一把鎖加外面，一把鎖加里面： class Singleton(object): __instance

單例模式的執行緒安全

package com.day3; public class SingleTonDemo { public static void main(String[] args) { SinleTonThread sinleTonThread=new SinleTonThread();

JAVA設計模式-單例模式(Singleton)執行緒安全與效率

一，前言 　　單例模式詳細大家都已經非常熟悉了，在文章單例模式的八種寫法比較中，對單例模式的概念以及使用場景都做了很不錯的說明。請在閱讀本文之前，閱讀一下這篇文章，因為本文就是按照這篇文章中的八種單例模式進行探索的。 　　本文的目的是：結合文章中的八種單例模式的寫法，使用實際的示例，來演示執行緒安全和效率 　

C++的單例模式與執行緒安全單例模式（懶漢/餓漢）

單例模式 單例模式：是一種常用的軟體設計模式。在它的核心結構中只包含一個被稱為單例的特殊類。通過單例模式可以保證系統中一個類只有一個例項。即一個類只有一個物件例項。 　　實現簡單的單例模式：建構函式宣告為private或protect防止被外部函式

Java五種單例模式與執行緒安全

單例模式是一種常用的軟體設計模式，常被用於一個類在系統中最多隻允許存在一個例項的場合，如視窗管理器、列印緩衝池、檔案系統等。在單例模式的核心結構中，只包含一個被稱為單例類的特殊類。通過單例模式可以保證系統中一個類只有一個例項而且該例項易於外界訪問，從而方便對例項個數的控制並節約系統資源。如果希望在系統中某個類

java單例模式（執行緒安全）

package cn.yang.test.controller; /**單例模式 * Created by Dev_yang on 2016/2/26. */ public class Singl

C++單例模式（執行緒安全、記憶體釋放）

一、懶漢模式：即第一次呼叫該類例項的時候才產生一個新的該類例項，並在以後僅返回此例項。 需要用鎖，來保證其執行緒安全性：原因：多個執行緒可能進入判斷是否已經存在例項的if語句，從而non thread safety. 使用double-check來保證thr

【設計模式】單例模式之執行緒類

好記性，不如爛筆頭。對於單例模式的理解和應用還是需要多多實踐，這次有感而發，寫份基於執行緒執行的單例模式。 單例模式該怎樣去實現：建構函式宣告為private或protect防止被外部函式例項化，內部

object-c 單例模式的執行緒安全

單例模式(Singleton Pattern)：保證一個類只有一個例項，並且提供一個訪問它的全域性訪問點。 單例在程式設計中是最常見的設計模式之一，下面我們來實現一個單例： Singleton.h 檔案 #import <Foundation/F

懶漢式單例模式為何執行緒不安全

這裡是一個懶漢式的示例程式碼：public class Singleton { private static Singleton s; private Singleton() { } public static Singleton getInstance

解決多執行緒單例模式的執行緒不安全問題

DCL雙檢查鎖機制 public class MyConfig { private volatile static MyConfig myConfig = null;//volatile

Spring bean 和單例bean的執行緒安全

Bean的作用域  　　Spring 3中為Bean定義了5中作用域，分別為singleton（單例）、prototype（原型）、request、session和global session，5種作用域說明如下： singleton：單例模式，Spring I

單例模式多執行緒

單例模式的多執行緒         比如使用者點選   程式正在操作這條資料的過程中  然後又有一個人點選  又把這條資料修改了  多執行緒會發生的問題 這時候 當第一個使用者點選後&nbs

單列模式之執行緒安全實現

單例模式有五種寫法：懶漢、餓漢、雙重檢驗鎖、靜態內部類、列舉   懶漢式執行緒不安全 public class Singleton { private static Singleton instance; private Singleton (){} publ

C# 基礎（十四）C#單例模式：首先介紹 單執行緒、多執行緒、加鎖 單例模式。然後介紹單例模式的執行緒同步：多執行緒有序訪問共享記憶體。

一、簡介 本篇文章將介紹如何使用單例模式，也就是類的例項化，在整個專案的生命週期內，只例項化一次。在單例模式中，往往可以看到如SourceCode.cs:這樣的結構的。 SourceCode.cs: public class Singleton { private static

列舉實現單例原理：執行緒安全及發序列化依舊為單例原因

單例的列舉實現在《Effective Java》中有提到，因為其功能完整、使用簡潔、無償地提供了序列化機制、在面對複雜的序列化或者反射攻擊時仍然可以絕對防止多次例項化等優點，單元素的列舉型別被作者認為是實現Singleton的最佳方法。 其實現非常簡單，如下：