2. 程式人生 > >設計模式 - 單例模式之多執行緒除錯與破壞單例

設計模式 - 單例模式之多執行緒除錯與破壞單例

阿新 • • 發佈：2019-10-10

前言

在之前的 設計模式 - 單例模式（詳解）看看和你理解的是否一樣？ 一文中，我們提到了通過Idea 開發工具進行多執行緒除錯、單例模式的暴力破壞的問題；由於篇幅原因，現在單獨開一篇文章進行演示：執行緒不安全的單例在多執行緒情況下為何被建立多個、如何破壞單例。

如果還不知道如何使用IDEA工具進行執行緒模式的除錯，請先閱讀我之前發的一篇文章： 你不知道的 IDEA Debug除錯小技巧

一、執行緒不安全的單例在多執行緒情況下為何被建立多個

首先回顧簡單執行緒不安全的懶漢式單例的程式碼以及測試程式程式碼：

/**
 * @author eamon.zhang
 * @date 2019-09-30 上午10:55
 */
public class LazySimpleSingleton {
    private LazySimpleSingleton(){}
    private static LazySimpleSingleton instance = null;

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

// 測試程式
@Test
public void test() {
    try {
        ConcurrentExecutor.execute(() -> {
            LazySimpleSingleton instance = LazySimpleSingleton.getInstance();
            System.out.println(Thread.currentThread().getName() + " : " + instance);
        }, 2, 2);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

對於這個單例，我們毫無疑問認為它是執行緒不安全的，至於為什麼，接下來使用IDEA工具的執行緒debug模式來直觀的找出答案。

在關鍵程式碼上打斷點

  1. 單例類LazySimpleSingleton的if (instance == null) 處：

  1. 測試類，多執行緒入口呼叫getInstance()處：

開始除錯

  1. 啟動 debug ，我們可以在除錯視窗找到我們啟動的執行緒：

  1. 將 pool-1-thread-1 執行緒單步執行到if (instance == null) 斷點處，觀察instance值為null；

  1. 將pool-1-thread-1執行到instance = new LazySimpleSingleton();
    處等待初始化：

  1. 切換執行緒 pool-1-thread-2 同樣單步執行到 if (instance == null) 斷點處，此時觀察instance值也為null（這就是我們常說的兩個執行緒同時執行到斷程式碼處）：

  1. 同樣將pool-1-thread-2執行到instance = new LazySimpleSingleton();處等待初始化：

  1. 顯然，這兩個執行緒都滿足if (instance == null) 的條件，都應該到對應的程式碼塊中執行例項化操作，那麼這兩個執行緒就會分別初始化：

執行緒 pool-1-thread-1 例項化後：

切換執行緒 pool-1-thread-2

觀察 instance 值已經被初始化了，但是，執行緒pool-1-thread-2 還是會被例項化一遍：

執行緒pool-1-thread-2例項化後：

大家是否一目瞭然了呢？

  1. 將兩個執行緒執行完，看控制檯：

大家可以看到，雖然輸出列印的物件是同一個，但是，確實是建立了兩遍，只不過 pool-1-thread-2 例項化後將 pool-1-thread-1例項化的物件值給覆蓋了。

當我將執行緒pool-1-thread-1和執行緒pool-1-thread-2同時執行到instance = new LazySimpleSingleton();處然後先讓pool-1-thread-1執行完列印後，再將pool-1-thread-2執行例項化操作，就會看到列印的物件會是不一樣的了：

這就是通過執行緒除錯模式手動控制執行緒執行順序來模擬還原多執行緒環境下，執行緒不安全的情況。

二、改進執行緒不安全的單例

我們明白了執行緒不安全的原因是兩個執行緒同時拿到的instance資源都為null，從而都進行例項化。那麼有沒有什麼方法能解決呢？當然有，給 getInstance()加 上 synchronized 關鍵字，使這個方法變成執行緒同步方法：

public class LazySimpleSingleton {
    private LazySimpleSingleton(){}
    private static LazySimpleSingleton instance = null;

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

當我們將其中一個執行緒執行並呼叫 getInstance()方法時，另一個執行緒在呼叫 getInstance()方法，執行緒的狀態由 RUNNING 變成了MONITOR,出現阻塞。直到第一個執行緒執行完，第二個執行緒才恢復 RUNNING 狀態繼續呼叫 getInstance() 方法

這就解決了之前所說的執行緒安全問題，但是這樣子線上程數量比較多情況下，如果 CPU分配壓力上升，會導致大批量執行緒出現阻塞，從而導致程式執行效能大幅下降；為了解決執行緒安全和程式效能問題，於是乎有了我們的雙重檢查式的單例。這裡就不再多說了。

三、破壞單例

一般情況下，我們建立使用餓漢式單例或雙重檢查的懶漢式單例是沒有問題的，但是在一定情況下，會發生單例被破壞。

反射破壞單例

實際情況下，公司一個程式設計師寫了一個單例，但是另外一個程式設計師，可能比較牛 X，寫程式碼風格有點不一樣，他通過反射來呼叫別人寫的介面，這就會出現此單例並非彼單例的情況。這就破壞了單例。

演示

在我們寫單例的時候，大家有沒有注意到私有的構造方法前面的修飾符僅為 private，如果我們使用反射來呼叫其構造方法，然後，再呼叫 getInstance()方法，應該就會有兩個不同的例項。

我們以前面說單例的文章中的 LazyInnerClassSingleton為例，編寫反射呼叫測試程式碼：

@Test
public void testReflex() {
    try {
        // 很無聊的情況下，進行破壞
        Class<LazyInnerClassSingleton> clazz = LazyInnerClassSingleton.class;
        // 通過反射拿到私有的構造方法
        Constructor<LazyInnerClassSingleton> c = clazz.getDeclaredConstructor(null);
        // 設定訪問屬性，強制訪問
        c.setAccessible(true);

        // 暴力初始化兩次，這就相當於呼叫了兩次構造方法
        LazyInnerClassSingleton o1 = c.newInstance();
        LazyInnerClassSingleton o2 = c.newInstance();
        // 只要 o1和o2 地址不相等，就可以說明這是兩個不同的物件，也就是違背了單例模式的初衷
        System.out.println(o1 == o2);
    } catch (Exception e) {
        e.printStackTrace();
    }

}

執行結果如下：

顯然，是建立了兩個不同的例項。現在，我們在其構造方法中做一些限制，一旦出現多次重複建立，則直接丟擲異常。來看優化後的程式碼：

public class LazyInnerClassSingleton {

    private LazyInnerClassSingleton() {
        if(LazyHolder.INSTANCE != null){
            throw new RuntimeException("不允許建立多個例項");
        }
    }

    // 注意關鍵字final，保證方法不被重寫和過載
    public static final LazyInnerClassSingleton getInstance() {
        return LazyHolder.INSTANCE;
    }

    private static class LazyHolder {
        // 注意 final 關鍵字（保證不被修改）
        private static final LazyInnerClassSingleton INSTANCE = new LazyInnerClassSingleton();
    }
}

再次呼叫：

至此，就避免了單例被反射破壞的問題。

序列化破壞單例

另外一種情況，可能會遇到，我們需要將物件序列化到磁碟，下次使用時再從磁碟反序列化回來，反序列化的物件會被重新分配記憶體，那如果序列化的物件為單例，則就違背了單例模式的初衷。這也相當於破壞了單例。

演示

我們還是以LazyInnerClassSingleton為例，將LazyInnerClassSingleton 實現 Serializable 介面；

然後編寫測試程式碼：

/**
 * @author eamon.zhang
 * @date 2019-10-08 下午3:06
 */
public class SerializableTest {
    public static void main(String[] args) {
        LazyInnerClassSingleton s1 = null;
        LazyInnerClassSingleton s2 = LazyInnerClassSingleton.getInstance();

        FileOutputStream fos = null;
        try {
            fos = new FileOutputStream("LazyInnerClassSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(s2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("LazyInnerClassSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            s1 = (LazyInnerClassSingleton)ois.readObject();
            ois.close();

            System.out.println(s1);
            System.out.println(s2);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

執行測試程式碼：

可以看到，結果為兩個不同的物件。這同樣違背了單例模式的初衷。那麼我們如何保證序列化的情況也能實現單例呢？其實也很簡單，使用 readResolve() 方法即可：

public class LazyInnerClassSingleton implements Serializable {

    private LazyInnerClassSingleton() {
        if (LazyHolder.INSTANCE != null) {
            throw new RuntimeException("不允許建立多個例項");
        }
    }

    // 注意關鍵字final，保證方法不被重寫和過載
    public static final LazyInnerClassSingleton getInstance() {
        return LazyHolder.INSTANCE;
    }

    private static class LazyHolder {
        // 注意 final 關鍵字（保證不被修改）
        private static final LazyInnerClassSingleton INSTANCE = new LazyInnerClassSingleton();
    }

    // 解決反序列化物件不一致問題
    private Object readResolve() {
        return LazyHolder.INSTANCE;
    }
}

大家肯定會問，why？

為了一探究竟，我們來看一下 JDK 原始碼，我們進入 ObjectInputStream 類的 readObject()方法：

public final Object readObject() throws IOException, ClassNotFoundException {
        if (this.enableOverride) {
            return this.readObjectOverride();
        } else {
            int outerHandle = this.passHandle;

            Object var4;
            try {
                Object obj = this.readObject0(false);
                this.handles.markDependency(outerHandle, this.passHandle);
                ClassNotFoundException ex = this.handles.lookupException(this.passHandle);
                if (ex != null) {
                    throw ex;
                }

                if (this.depth == 0L) {
                    this.vlist.doCallbacks();
                    this.freeze();
                }

                var4 = obj;
            } finally {
                this.passHandle = outerHandle;
                if (this.closed && this.depth == 0L) {
                    this.clear();
                }

            }

            return var4;
        }
    }

我們發現：readObject 中又呼叫了我們重寫的 readObject0()方法，進入 readObject0()方法：

private Object readObject0(boolean unshared) throws IOException {
        ...
        try {
            switch(tc) {
            ...
            case 115:
                var4 = this.checkResolve(this.readOrdinaryObject(unshared));
                return var4;
            ...
        } finally {
            --this.depth;
            this.bin.setBlockDataMode(oldMode);
        }

        return var4;
    }

我們看到程式碼中呼叫了 ObjectInputStream 的 readOrdinaryObject() 方法，我們繼續進入看原始碼：

private Object readOrdinaryObject(boolean unshared) throws IOException {
        ...
            if (cl != String.class && cl != Class.class && cl != ObjectStreamClass.class) {
                Object obj;
                try {
                    obj = desc.isInstantiable() ? desc.newInstance() : null;
                } catch (Exception var7) {
                    throw (IOException)(new InvalidClassException(desc.forClass().getName(), "unable to create instance")).initCause(var7);
                }

        ...

        }
    }

發現呼叫了 ObjectStreamClass 的 isInstantiable()方法，而 isInstantiable()裡面的程式碼如下:

boolean isInstantiable() {
    this.requireInitialized();
    return this.cons != null;
}

程式碼非常簡單，就是判斷一下構造方法是否為空，構造方法不為空就返回 true，也就是說，只要有無參構造方法就會例項化；這時候，其實還沒有找到為什麼加上readResolve()方法就避免了單例被破壞的真正原因，我們再次回到ObjectInputStream 的 readOrdinaryObject()方法繼續往下看可以找到如下程式碼：

private Object readOrdinaryObject(boolean unshared) throws IOException {
    ...
    if (obj != null && this.handles.lookupException(this.passHandle) == null && desc.hasReadResolveMethod()) {
        Object rep = desc.invokeReadResolve(obj);
        if (unshared && rep.getClass().isArray()) {
            rep = cloneArray(rep);
        }

        if (rep != obj) {
            if (rep != null) {
                if (rep.getClass().isArray()) {
                    this.filterCheck(rep.getClass(), Array.getLength(rep));
                } else {
                    this.filterCheck(rep.getClass(), -1);
                }
            }

            obj = rep;
            this.handles.setObject(this.passHandle, rep);
        }
    }
    ...
}

判斷無參構造方法是否存在之後，又呼叫了 hasReadResolveMethod()方法：

boolean hasReadResolveMethod() {
    this.requireInitialized();
    return this.readResolveMethod != null;
}

邏輯非常簡單，就是判斷readResolveMethod 是否為空，不為空就返回 true。那麼 readResolveMethod是在哪裡賦值的呢? 通過全域性查詢找到了賦值程式碼在私有方法 ObjectStreamClass()方法中給 readResolveMethod 進行賦值，來看程式碼:

 ObjectStreamClass.this.readResolveMethod = ObjectStreamClass.getInheritableMethod(cl, "readResolve", (Class[])null, Object.class);

程式碼的邏輯其實就是通過反射找到一個無參的 readResolve()方法，並且儲存下來，現在再回到 ObjectInputStream 的 readOrdinaryObject() 方法繼續往下看，如果readResolve()存在則呼叫 invokeReadResolve()方法：

Object invokeReadResolve(Object obj) throws IOException, UnsupportedOperationException {
    this.requireInitialized();
    if (this.readResolveMethod != null) {
        try {
            return this.readResolveMethod.invoke(obj, (Object[])null);
        } catch (InvocationTargetException var4) {
            Throwable th = var4.getTargetException();
            if (th instanceof ObjectStreamException) {
                throw (ObjectStreamException)th;
            } else {
                throwMiscException(th);
                throw new InternalError(th);
            }
        } catch (IllegalAccessException var5) {
            throw new InternalError(var5);
        }
    } else {
        throw new UnsupportedOperationException();
    }
}

我們可以看到在 invokeReadResolve()方法中用反射呼叫了 readResolveMethod() 方法。 通過JDK原始碼分析我們可以看出，雖然，增加 readResolve()方法返回例項，解決了單例被破壞的問題。但是，我們通過分析原始碼以及除錯，我們可以看到實際上例項化了兩 次，只不過新建立的物件沒有被返回而已.

那如果，建立物件的動作發生頻率增大，就 意味著記憶體分配開銷也就隨之增大；為了解決這個問題，我們推薦使用註冊式單例。

為何建議使用註冊式（列舉式）單例

我們在前文中說到了，我們極力推薦使用列舉型別的單例；接下來我們分析一下原因：

使用 Java 反編譯工具 Jad(自行下載)，解壓後，使用命令列呼叫：

./jad ~/IdeaProjects/own/java-advanced/01.DesignPatterns/design-patterns/build/classes/java/main/com/eamon/javadesignpatterns/singleton/enums/EnumSingleton.class

會在當前目錄生成一個 EnumSingleton.jad檔案，我們使用 vscode 開啟這個檔案檢視：

public final class EnumSingleton extends Enum
{

    public static EnumSingleton[] values()
    {
        return (EnumSingleton[])$VALUES.clone();
    }

    public static EnumSingleton valueOf(String name)
    {
        return (EnumSingleton)Enum.valueOf(com/eamon/javadesignpatterns/singleton/enums/EnumSingleton, name);
    }

    private EnumSingleton(String s, int i)
    {
        super(s, i);
        instance = new EnumResource();
    }

    public Object getInstance()
    {
        return instance;
    }

    public static final EnumSingleton INSTANCE;
    private Object instance;
    private static final EnumSingleton $VALUES[];

    static
    {
        INSTANCE = new EnumSingleton("INSTANCE", 0);
        $VALUES = (new EnumSingleton[] {
            INSTANCE
        });
    }
}

請注意這段程式碼：

static
{
    INSTANCE = new EnumSingleton("INSTANCE", 0);
    $VALUES = (new EnumSingleton[] {
        INSTANCE
    });
}

原來列舉類單例在靜態程式碼塊中就給INSTANCE 賦了值，是餓漢式單例的實現方式。那麼同樣的，我們能否通過反射和序列化方式進行破壞呢？

先分析通過序列化方式：

我們還是回到JDK原始碼：在 ObjectInputStream 的 readObject0()方法中有如下程式碼：

 private Object readObject0(boolean unshared) throws IOException {
    ...
        case 126:
            var4 = this.checkResolve(this.readEnum(unshared));
    ...

    return var4;
}

我們看到 readObject0()中呼叫了readEnum()方法，跟進該方法：

private Enum<?> readEnum(boolean unshared) throws IOException {
    if (this.bin.readByte() != 126) {
        throw new InternalError();
    } else {
        ObjectStreamClass desc = this.readClassDesc(false);
        if (!desc.isEnum()) {
            throw new InvalidClassException("non-enum class: " + desc);
        } else {
            int enumHandle = this.handles.assign(unshared ? unsharedMarker : null);
            ClassNotFoundException resolveEx = desc.getResolveException();
            if (resolveEx != null) {
                this.handles.markException(enumHandle, resolveEx);
            }

            String name = this.readString(false);
            Enum<?> result = null;
            Class<?> cl = desc.forClass();
            if (cl != null) {
                try {
                    Enum<?> en = Enum.valueOf(cl, name);
                    result = en;
                } catch (IllegalArgumentException var9) {
                    throw (IOException)(new InvalidObjectException("enum constant " + name + " does not exist in " + cl)).initCause(var9);
                }

                if (!unshared) {
                    this.handles.setObject(enumHandle, result);
                }
            }

            this.handles.finish(enumHandle);
            this.passHandle = enumHandle;
            return result;
        }
    }
}

我們發現列舉型別其實通過類名和 Class 物件類找到一個唯一的列舉物件。因此，列舉物件不可能被類載入器載入多次。

那麼是否可以通過反射進行破壞呢？我們先來執行以下反射破壞列舉類的測試程式碼：

@Test
public void testEnum(){
    try {
        // 很無聊的情況下，進行破壞
        Class<EnumSingleton> clazz = EnumSingleton.class;
        // 通過反射拿到私有的構造方法
        Constructor<EnumSingleton> c = clazz.getDeclaredConstructor(null);
        // 設定訪問屬性，強制訪問
        c.setAccessible(true);

        // 暴力初始化兩次，這就相當於呼叫了兩次構造方法
        EnumSingleton o1 = c.newInstance();
        EnumSingleton o2 = c.newInstance();
        // 只要 o1和o2 地址不相等，就可以說明這是兩個不同的物件，也就是違背了單例模式的初衷
        System.out.println(o1 == o2);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

執行結果：

報的是 java.lang.NoSuchMethodException 異常，意思是沒找到無參的構造方法。

那麼我們來看一下 java.lang.Enum 的原始碼，我們發現它只有一個protected的構造方法:

protected Enum(String name, int ordinal) {
    this.name = name;
    this.ordinal = ordinal;
}

那我們來做一個這樣的測試：

@Test
public void testEnum1() {
    try {
        Class clazz = EnumSingleton.class;
        Constructor c = clazz.getDeclaredConstructor(String.class, int.class);
        c.setAccessible(true);
        EnumSingleton enumSingleton = (EnumSingleton) c.newInstance("Eamon", 666);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

發現控制檯輸出如下錯誤：

意思就是不能用反射來建立列舉型別。至於為什麼，我們還是來看 JDK 原始碼，進入Constructor的newInstance()方法中：

    public T newInstance(Object... initargs) throws InstantiationException, IllegalAccessException, IllegalArgumentException, InvocationTargetException {
        if (!this.override) {
            Class<?> caller = Reflection.getCallerClass();
            this.checkAccess(caller, this.clazz, this.clazz, this.modifiers);
        }

        if ((this.clazz.getModifiers() & 16384) != 0) {
            throw new IllegalArgumentException("Cannot reflectively create enum objects");
        } else {
            ConstructorAccessor ca = this.constructorAccessor;
            if (ca == null) {
                ca = this.acquireConstructorAccessor();
            }

            T inst = ca.newInstance(initargs);
            return inst;
        }
    }

原來，在原始碼中對列舉型別進行了強制性的判斷（16384代表列舉型別）,如果是列舉型別，直接拋異常。到此為止也就說明了為什麼《Effective Java》推薦使用列舉來實現單例的原因： JDK 列舉的語法特殊性，以及反射也為列舉保駕護航，讓列舉式單例成為一種比較優雅的實現。

本文中所涉及的原始碼可在 github 上找到，相關的測試程式碼在 test 包下：https://github.com/eamonzzz/java-advan

相關推薦

設計模式 - 單例模式之多執行緒除錯與破壞單例

前言 在之前的 設計模式 - 單例模式（詳解）看看和你理解的是否一樣？ 一文中，我們提到了通過Idea 開發工具進行多執行緒除錯、單例模式的暴力破壞的問題；由於篇幅原因，現在單獨開一篇文章進行演示：執行緒不安全的單例在多執行緒情況下為何被建立多個、如何破壞單例。 如果還不知道如何使用IDEA工具進行執行緒模

多執行緒併發問題以及單例設計模式與執行緒安全以及同步方法和同步程式碼塊

執行緒安全和非執行緒安全 在作業系統中，執行緒是不擁有資源的，程序擁有資源。執行緒是由程序建立的，一個程序可以建立多個執行緒，這些執行緒共享程序中的資源。當多個執行緒同時操作一個變數時，這個時候就可能會造成資料的不一致性，此時就是執行緒不安全。 JVM有主記

Java多執行緒知識點總結——進階篇（五）之多執行緒下的單例模式

餓漢式 餓漢式多執行緒和單執行緒的程式碼是一樣的，如下： class Single { private static final Single s = new Single(); p

Java 多執行緒（四）—— 單例模式

這篇部落格介紹執行緒安全的應用——單例模式。 單例模式   單例模式，是一種常用的軟體設計模式。在它的核心結構中只包含一個被稱為單例的特殊類。通過單例模式可以保證系統中，應用該模式的類一個類只有一個例項。即一個類只有一個物件例項。 例項: /** * @author

如何正確實現多執行緒環境中的單例模式

要實現單例模式，馬上可以想到的有三種方法： 餓漢式 懶漢式 有且只有一個例項的列舉 如何正確地在多執行緒環境下實現單例模式呢？ 對於 餓漢式 和 單例項列舉 來說，它們都是利用jvm類載入機制來實現單例模式。使用這兩種方法，無論是否是在多執行緒環境中，都

Java多執行緒核心技術(五)單例模式與多執行緒

本文只需要考慮一件事：如何使單例模式遇到多執行緒是安全的、正確的 1.立即載入 / "餓漢模式" 什麼是立即載入？立即載入就是使用類的時候已經將物件建立完畢，常見的實現辦法就是直接 new 例項化。 public class MyObject { private static MyObject m

C# 多執行緒啟動和管理 單例模式

1.          List<Task> taskList = new List<Task>();             TaskFactory t

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

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

多執行緒併發下的單例模式實現

1.1 天生執行緒安全的餓漢式單例 1.2 懶漢式單例 1.2.1 執行緒不安全的懶漢式單例 1.2.2 執行緒安全的懶漢式單例

多執行緒下的懶漢式單例模式

       在多執行緒下實現懶漢式單例模式是不安全的，所謂的不安全，就是在同一時間段有兩個執行緒同時執行一段程式碼。解決方法包括將懶漢式改為餓漢式或者讓執行緒同步。下面程式碼實現執行緒的同步，保證多

【多執行緒核心技術】---單例模式與多執行緒

立即載入/“餓漢模式”    立即載入就是在使用類的時候已經將物件建立完畢，常見的實現辦法就是直接new例項化。立即載入/“餓漢模式”    延遲載入就是在呼叫get（）方法時例項化才被建立，常見的實現方式就是在get（）方法中進行new（）例項化，    在多執行緒環境下會

多執行緒情況下，單例模式的實現方式

方式1（推薦）package singleton; public class Singletion { private static class InnerSingletion { priv

JavaSE基礎學習筆記及案例(二)多執行緒(下)與簡單工廠模式的瞭解

1.多執行緒(下) 1.1單例設計模式：保證類在記憶體中只存在一個物件 ************餓漢式與懶漢式的區別【面試題】 餓漢式單例模式：以空間換時間 懶漢式單例模式：以時間換空間（不推薦使用，僅在面試中用到） 3.多執行緒訪問時：餓漢式不會建立多個物件；而懶漢式

Java基礎之多執行緒案例-單生產單消費

在講單生產單消費之前，我們先來說一下執行緒間通訊的問題 一、 執行緒間通訊 概念：多個執行緒在處理同一個資源，但是處理的動作（執行緒的任務）卻不相同。 比如：執行緒A用來生成包子的，執行緒B用來吃包子的，包子可以理解為同一資源，執行緒A與執行緒B處理的動作，一個是生產，一個是消費，

java day25 多執行緒（下） 單例類（Runtime,Timer

25.01_多執行緒(單例設計模式)(掌握) 單例設計模式：保證類在記憶體中只有一個物件。 如何保證類在記憶體中只有一個物件呢？ (1)控制類的建立，不讓其他類來建立本類的物件。private (2)在本類中定義一個本類的物件。Singl

Python之多執行緒：python多執行緒設計之同時執行多個函式命令詳細攻略

Python之多執行緒：python多執行緒設計之同時執行多個函式命令詳細攻略 目的 同時執行多個函式命令   採取方法 T1、單個實現 import threading threading.Thread(target=my_record()).start(

Caffe:CPU模式下使用openblas-openmp(多執行緒版本)

從所周知，所有的深度學習框架使用GPU執行是最快的，但是在不具備Nvidia顯示卡的環境下只使用CPU來執行，慢就慢點吧，對於學習階段還是夠用的。 Caffe用到的Blas可以選擇Altas,OpenBlas,Intel MKL,Blas承擔了大量了數學工作，

淺談多執行緒中的懶漢式單例

1.場景：我們都知道在應用開發中有時會使用到單例設計模式，那麼今天我們就淺談一下單例中的一種-懶漢式。 顧名思義懶漢式其實是一個很有意思的名字，懶漢在我們開發中常說的用到了才去建立物件。此種生成方式遇到多執行緒又會擦出怎樣的火花呢？ public class Singlet

Python爬蟲之多執行緒，多程序

前言 我們之前寫的爬蟲都是單個執行緒的？這怎麼夠？一旦一個地方卡到不動了，那不就永遠等待下去了？為此我們可以使用多執行緒或者多程序來處理。 首先宣告一點！ 多執行緒和多程序是不一樣的！一個是 thread 庫，一個是 multiprocessing 庫。而多執行緒 thread 在 Pytho

java面試/筆試題目之多執行緒及鎖 (持續更新中)

前言：這一模組可以參照徐劉根大佬的部落格。 一.執行緒和程序的概念、並行和併發的概念 1.程序：是計算機中的程式關於某資料集合上的一次執行活動，是系統 進行資源分配和排程的基本單位，是作業系統結構的基礎。程式是指令、資料及其組織形式的描述，程序是程式的實體。 2.執行緒：是程式執行流的