繼上一篇筆記之後，今天我們討論一下 代碼中是存在註釋是否是一件好的事情。

 

在我們開發的過程中講究“名副其實，見名識意”，這也往往是很多公司的要求，但是有了這些要求是不是我們的代碼中如果存在註釋是不是意味着我們的 函數，變量，以及類 的命名就不符合了“名副其實，見名識意”。

我們先區分一下註釋的類別，註釋一般分為以下幾種：

• 1， 單行註釋
• 2， 多行註釋
• 3， 文檔註釋
• 4， #region 摺疊註釋，可以將 代碼摺疊

 註釋的類別

1， 單行註釋：

在以 “//” 開頭，用以說明一行代碼的作用放置位置 看習慣或者公司要求合理就行。常用於函數內部，在很多的開源代碼中文件的頭部我同樣見到很多人使用單行註釋進行說明，靈活就好。
體現形式如下：

 public List<string> getVipUserNameByUserType()
          {
            // Vip user name list
            var vipUserNames = new List<string>();

            foreach (var user in Users)
            {

                if (user.Type = "VIP")

                    vipUserNames.Add(user.Name);
            }
            return vipUserNames;

          }

View Code

2， 多行註釋：

以“/*”開頭 “*/” 結尾 常用於描述說明一段代碼以及類註釋或者說代碼塊常用於文件的頂部。說明作者信息，時間如果是開源的這包含開源的更多說明。
通常使用如下:

/*
    * 作者：〈版權〉
    * 描述：〈描述〉
    * 創建時間：YYYY-MM-DD
    * 作用：
*/

View Code

3， 文檔註釋：

也就是常用的XML 註釋：它的說明性更加的強烈，多用於類以及函數上，當然屬性上同樣可以使用：
如下所示：

        /// <summary>
        /// MyClass
        /// </summary>
        public class MyClass
        {
            /// <summary>
            /// MyProperty
            /// </summary>
            public int MyProperty { get; set; }
            /// <summary>
            /// MyMethod
            /// </summary>
            public void MyMethod(){  }
        }

View Code

以下是官方建議的文檔標記 點擊標籤會制動跳轉

 

4， #region ： 摺疊註釋，常用於描述多個函數的基本作用

書中最喜歡的話

好的註釋不能美化糟糕的代碼，真正好的註釋是你想盡辦法不去謝的註釋。懷註釋都是糟糕代碼的支撐或借口，或者是對錯誤決策的修正。

下面看一個例子

       //Check to see if the employee is eligible for full benefits
（1）If((employee.flags & HOURLY_FLAG)&& (employee.age>65))

（2）If(employee.isEligibleForFullBenefits()))

  這兩個你更喜歡哪個

View Code

好的註釋的特徵：

1：表示法律信息（這樣的註釋一般出現在文檔頂部說明作用以及協議）

// Copyright (c) .NET Foundation. All rights reserved
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.

View Code

2：提供信息的註釋（指無法通過命名提供信息如要 註釋輔助的）

public void ConfigureServices(IServiceCollection services)
{

// These two middleware are registered via an IStartupFilter in UseIISIntegration but you can configure them here.

services.Configure<IISOptions>(options =>
{});

}

View Code

3：對意圖的解釋

4： 警示：告知其他人會出現某種後果的註釋

5： TODO註釋： 主要描述應該做的目前還沒有做的事情。

6： 放大：提示不合理之物的重要性。

應避免的註釋

應該避免以下幾點：

1： 誤導性註釋

2： 日誌式註釋

3： 廢話註釋

4： 標記位置的註釋

5： 括號后的註釋

6： 歸屬與簽名

7： 註釋掉的代碼

8： Html 註釋

以上沒有一一舉例的原因是我的PPT是一份演示的PPT，裏面很多公司的代碼不便貼出，抱歉。

不足之處還請指出

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※公開收購3c價格,不怕被賤賣!

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

為更良好的閱讀體驗，請訪問原文：

一、前言

當我們使用計算機時，可以同時做許多事情，例如一邊打遊戲一邊聽音樂。這是因為操作系統支持併發任務，從而使得這些工作得以同時進行。

• 那麼提出一個問題：如果我們要實現一個程序能一邊聽音樂一邊玩遊戲怎麼實現呢？

public class Tester {

    public static void main(String[] args) {
        System.out.println("開始....");
        playGame();
        playMusic();
        System.out.println("結束....");
    }

    private static void playGame() {
        for (int i = 0; i < 50; i++) {
            System.out.println("玩遊戲" + i);
        }
    }

    private static void playMusic() {
        for (int i = 0; i < 50; i++) {
            System.out.println("播放音樂" + i);
        }
    }
}

我們使用了循環來模擬過程，因為播放音樂和打遊戲都是連續的，但是結果卻不盡人意，因為函數體總是要執行完之後才能返回。那麼到底怎麼解決這個問題？

并行與併發

并行性和併發性是既相似又有區別的兩個概念。

并行性是指兩個或多個事件在同一時刻發生。而併發性是指兩個或多個事件在同一時間間隔內發生。

在多道程序環境下，併發性是指在一段時間內宏觀上有多個程序在同時運行，但在單處理機環境下（一個處理器），每一時刻卻僅能有一道程序執行，故微觀上這些程序只能是分時地交替執行。例如，在 1 秒鐘時間內，0 – 15 ms 程序 A 運行；15 – 30 ms 程序 B 運行；30 – 45 ms 程序 C 運行；45 – 60 ms 程序 D 運行，因此可以說，在 1 秒鐘時間間隔內，宏觀上有四道程序在同時運行，但微觀上，程序 A、B、C、D 是分時地交替執行的。

如果在計算機系統中有多個處理機，這些可以併發執行的程序就可以被分配到多個處理機上，實現併發執行，即利用每個處理機愛處理一個可併發執行的程序。這樣，多個程序便可以同時執行。以此就能提高系統中的資源利用率，增加系統的吞吐量。

進程和線程

進程是指一個內存中運行的應用程序。一個應用程序可以同時啟動多個進程，那麼上面的問題就有了解決的思路：我們啟動兩個進程，一個用來打遊戲，一個用來播放音樂。這當然是一種解決方案，但是想象一下，如果一個應用程序需要執行的任務非常多，例如 LOL 遊戲吧，光是需要播放的音樂就有非常多，人物本身的語音，技能的音效，遊戲的背景音樂，塔攻擊的聲音等等等，還不用說遊戲本身，就光播放音樂就需要創建許多許多的進程，而進程本身是一種非常消耗資源的東西，這樣的設計顯然是不合理的。更何況大多數的操作系統都不需要一個進程訪問其他進程的內存空間，也就是說，進程之間的通信很不方便，此時我們就得引入“線程”這門技術，來解決這個問題。

線程是指進程中的一個執行任務（控制單元），一個進程可以同時併發運行多個線程。我們可以打開任務管理器，觀察到幾乎所有的進程都擁有着許多的「線程」(在 WINDOWS 中線程是默認隱藏的，需要在「查看」裏面點擊「選擇列」，有一個線程數的勾選項，找到並勾選就可以了)。

進程和線程的區別

進程：有獨立的內存空間，進程中的數據存放空間（堆空間和棧空間）是獨立的，至少有一個線程。

線程：堆空間是共享的，棧空間是獨立的，線程消耗的資源也比進程小，相互之間可以影響的，又稱為輕型進程或進程元。

因為一個進程中的多個線程是併發運行的，那麼從微觀角度上考慮也是有先後順序的，那麼哪個線程執行完全取決於 CPU 調度器(JVM 來調度)，程序員是控制不了的。我們可以把多線程併發性看作是多個線程在瞬間搶 CPU 資源，誰搶到資源誰就運行，這也造就了多線程的隨機性。下面我們將看到更生動的例子。

Java 程序的進程(Java 的一個程序運行在系統中)里至少包含主線程和垃圾回收線程(後台線程)，你可以簡單的這樣認為，但實際上有四個線程（了解就好）：

• [1] main——main 線程，用戶程序入口
• [2] Reference Handler——清除 Reference 的線程
• [3] Finalizer——調用對象 finalize 方法的線程
• [4] Signal Dispatcher——分發處理髮送給 JVM 信號的線程

多線程和單線程的區別和聯繫？

1. 單核 CPU 中，將 CPU 分為很小的時間片，在每一時刻只能有一個線程在執行，是一種微觀上輪流佔用 CPU 的機制。

2. 多線程會存在線程上下文切換，會導致程序執行速度變慢，即採用一個擁有兩個線程的進程執行所需要的時間比一個線程的進程執行兩次所需要的時間要多一些。

結論：即採用多線程不會提高程序的執行速度，反而會降低速度，但是對於用戶來說，可以減少用戶的響應時間。

多線程的優勢

儘管面臨很多挑戰，多線程有一些優點仍然使得它一直被使用，而這些優點我們應該了解。

優勢一：資源利用率更好

想象一下，一個應用程序需要從本地文件系統中讀取和處理文件的情景。比方說，從磁盤讀取一個文件需要 5 秒，處理一個文件需要 2 秒。處理兩個文件則需要：

1| 5秒讀取文件A
2| 2秒處理文件A
3| 5秒讀取文件B
4| 2秒處理文件B
5| ---------------------
6| 總共需要14秒

從磁盤中讀取文件的時候，大部分的 CPU 時間用於等待磁盤去讀取數據。在這段時間里，CPU 非常的空閑。它可以做一些別的事情。通過改變操作的順序，就能夠更好的使用 CPU 資源。看下面的順序：

1| 5秒讀取文件A
2| 5秒讀取文件B + 2秒處理文件A
3| 2秒處理文件B
4| ---------------------
5| 總共需要12秒

CPU 等待第一個文件被讀取完。然後開始讀取第二個文件。當第二文件在被讀取的時候，CPU 會去處理第一個文件。記住，在等待磁盤讀取文件的時候，CPU 大部分時間是空閑的。

總的說來，CPU 能夠在等待 IO 的時候做一些其他的事情。這個不一定就是磁盤 IO。它也可以是網絡的 IO，或者用戶輸入。通常情況下，網絡和磁盤的 IO 比 CPU 和內存的 IO 慢的多。

優勢二：程序設計在某些情況下更簡單

在單線程應用程序中，如果你想編寫程序手動處理上面所提到的讀取和處理的順序，你必須記錄每個文件讀取和處理的狀態。相反，你可以啟動兩個線程，每個線程處理一個文件的讀取和操作。線程會在等待磁盤讀取文件的過程中被阻塞。在等待的時候，其他的線程能夠使用 CPU 去處理已經讀取完的文件。其結果就是，磁盤總是在繁忙地讀取不同的文件到內存中。這會帶來磁盤和 CPU 利用率的提升。而且每個線程只需要記錄一個文件，因此這種方式也很容易編程實現。

優勢三：程序響應更快

有時我們會編寫一些較為複雜的代碼（這裏的複雜不是說複雜的算法，而是複雜的業務邏輯），例如，一筆訂單的創建，它包括插入訂單數據、生成訂單趕快找、發送郵件通知賣家和記錄貨品銷售數量等。用戶從單擊“訂購”按鈕開始，就要等待這些操作全部完成才能看到訂購成功的結果。但是這麼多業務操作，如何能夠讓其更快地完成呢？

在上面的場景中，可以使用多線程技術，即將數據一致性不強的操作派發給其他線程處理（也可以使用消息隊列），如生成訂單快照、發送郵件等。這樣做的好處是響應用戶請求的線程能夠盡可能快地處理完成，縮短了響應時間，提升了用戶體驗。

其他優勢

多線程還有一些優勢也顯而易見：

• 進程之前不能共享內存，而線程之間共享內存(堆內存)則很簡單。
• 系統創建進程時需要為該進程重新分配系統資源,創建線程則代價小很多,因此實現多任務併發時,多線程效率更高.
• Java 語言本身內置多線程功能的支持,而不是單純地作為底層系統的調度方式,從而簡化了多線程編程.

上下文切換

即使是單核處理器也支持多線程執行代碼，CPU 通過給每個線程分配 CPU 時間片來實現這個機制。時間片是 CPU 分配給各個線程的時間，因為時間片非常短，所以 CPU 通過不停地切換線程執行，讓我們感覺多個線程是同時執行的，時間片一般是幾十毫秒（ms）。

CPU 通過時間片分配算法來循環執行任務，當前任務執行一個時間片後會切換到下一個任務。但是，在切換前會保存上一個任務的狀態，以便下次切換回這個任務的時候，可以再加載這個任務的狀態。所以任務從保存到再加載的過程就是一次上下文切換。

這就像我們同時讀兩本書，當我們在讀一本英文的技術書時，發現某個單詞不認識，於是打開中英文字典，但是在放下英文技術書之前，大腦必須先記住這本書獨到了多少頁的多少行，等查完單詞之後，能夠繼續讀這本書。這樣的切換是會影響讀書效率的，同樣上下文切換也會影響多線程的執行速度。

二、創建線程的兩種方式

繼承 Thread 類

public class Tester {

    // 播放音樂的線程類
    static class PlayMusicThread extends Thread {

        // 播放時間，用循環來模擬播放的過程
        private int playTime = 50;

        public void run() {
            for (int i = 0; i < playTime; i++) {
                System.out.println("播放音樂" + i);
            }
        }
    }

    // 方式1：繼承 Thread 類
    public static void main(String[] args) {
        // 主線程：運行遊戲
        for (int i = 0; i < 50; i++) {
            System.out.println("打遊戲" + i);
            if (i == 10) {
                // 創建播放音樂線程
                PlayMusicThread musicThread = new PlayMusicThread();
                musicThread.start();
            }
        }
    }
}

運行結果發現打遊戲和播放音樂交替出現，說明已經成功了。

實現 Runnable 接口

public class Tester {

    // 播放音樂的線程類
    static class PlayMusicThread implements Runnable {

        // 播放時間，用循環來模擬播放的過程
        private int playTime = 50;

        public void run() {
            for (int i = 0; i < playTime; i++) {
                System.out.println("播放音樂" + i);
            }
        }
    }

    // 方式2：實現 Runnable 方法
    public static void main(String[] args) {
        // 主線程：運行遊戲
        for (int i = 0; i < 50; i++) {
            System.out.println("打遊戲" + i);
            if (i == 10) {
                // 創建播放音樂線程
                Thread musicThread = new Thread(new PlayMusicThread());
                musicThread.start();
            }
        }
    }
}

也能完成效果。

以上就是傳統的兩種創建線程的方式，事實上還有第三種，我們後邊再講。

多線程一定快嗎？

先來一段代碼，通過并行和串行來分別執行累加操作，分析：下面的代碼併發執行一定比串行執行快嗎？

import org.springframework.util.StopWatch;

// 比較并行和串行執行累加操作的速度
public class Tester {

    // 執行次數
    private static final long COUNT = 100000000;
    private static final StopWatch TIMER = new StopWatch();

    public static void main(String[] args) throws InterruptedException {
        concurrency();
        serial();
        // 打印比較測試結果
        System.out.println(TIMER.prettyPrint());
    }

    private static void serial() {
        TIMER.start("串行執行" + COUNT + "條數據");

        int a = 0;
        for (long i = 0; i < COUNT; i++) {
            a += 5;
        }
        // 串行執行
        int b = 0;
        for (long i = 0; i < COUNT; i++) {
            b--;
        }

        TIMER.stop();
    }

    private static void concurrency() throws InterruptedException {
        TIMER.start("并行執行" + COUNT + "條數據");

        // 通過匿名內部類來創建線程
        Thread thread = new Thread(() -> {
            int a = 0;
            for (long i = 0; i < COUNT; i++) {
                a += 5;
            }
        });
        thread.start();

        // 并行執行
        int b = 0;
        for (long i = 0; i < COUNT; i++) {
            b--;
        }
        // 等待線程結束
        thread.join();
        TIMER.stop();
    }
}

大家可以自己測試一下，每一台機器 CPU 不同測試結果可能也會不同，之前在 WINDOWS 本兒上測試的時候，多線程的優勢從 1 千萬數據的時候才開始體現出來，但是現在換了 MAC，1 億條數據時間也差不多，到 10 億的時候明顯串行就比并行快了… 總之，為什麼併發執行的速度會比串行慢呢？就是因為線程有創建和上下文切換的開銷。

繼承 Thread 類還是實現 Runnable 接口？

想象一個這樣的例子：給出一共 50 個蘋果，讓三個同學一起來吃，並且給蘋果編上號碼，讓他們吃的時候順便要說出蘋果的編號：

運行結果可以看到，使用繼承方式實現，每一個線程都吃了 50 個蘋果。這樣的結果顯而易見：是因為顯式地創建了三個不同的 Person 對象，而每個對象在堆空間中有獨立的區域來保存定義好的 50 個蘋果。

而使用實現方式則滿足要求，這是因為三個線程共享了同一個 Apple 對象，而對象中的 num 數量是一定的。

所以可以簡單總結出繼承方式和實現方式的區別：

繼承方式：

1. Java 中類是單繼承的，如果繼承了 Thread 了，該類就不能再有其他的直接父類了；
2. 從操作上分析，繼承方式更簡單，獲取線程名字也簡單..(操作上，更簡單)
3. 從多線程共享同一個資源上分析，繼承方式不能做到…

實現方式：

1. Java 中類可以實現多個接口，此時該類還可以繼承其他類，並且還可以實現其他接口(設計上，更優雅)..
2. 從操作上分析，實現方式稍微複雜點，獲取線程名字也比較複雜，需要使用 Thread.currentThread() 來獲取當前線程的引用..
3. 從多線程共享同一個資源上分析，實現方式可以做到..

在這裏，三個同學完成搶蘋果的例子，使用實現方式才是更合理的方式。

對於這兩種方式哪種好並沒有一個確定的答案，它們都能滿足要求。就我個人意見，我更傾向於實現 Runnable 接口這種方法。因為線程池可以有效的管理實現了 Runnable 接口的線程，如果線程池滿了，新的線程就會排隊等候執行，直到線程池空閑出來為止。而如果線程是通過實現 Thread 子類實現的，這將會複雜一些。

有時我們要同時融合實現 Runnable 接口和 Thread 子類兩種方式。例如，實現了 Thread 子類的實例可以執行多個實現了 Runnable 接口的線程。一個典型的應用就是線程池。

常見錯誤：調用 run() 方法而非 start() 方法

創建並運行一個線程所犯的常見錯誤是調用線程的 run() 方法而非 start() 方法，如下所示：

1| Thread newThread = new Thread(MyRunnable());
2| newThread.run();  //should be start();

起初你並不會感覺到有什麼不妥，因為 run() 方法的確如你所願的被調用了。但是，事實上，run() 方法並非是由剛創建的新線程所執行的，而是被創建新線程的當前線程所執行了。也就是被執行上面兩行代碼的線程所執行的。想要讓創建的新線程執行 run() 方法，必須調用新線程的 start() 方法。

三、線程的安全問題

吃蘋果遊戲的不安全問題

我們來考慮一下上面吃蘋果的例子，會有什麼問題？

儘管，Java 並不保證線程的順序執行，具有隨機性，但吃蘋果比賽的案例運行多次也並沒有發現什麼太大的問題。這並不是因為程序沒有問題，而只是問題出現的不夠明顯，為了讓問題更加明顯，我們使用 Thread.sleep() 方法（經常用來模擬網絡延遲）來讓線程休息 10 ms，讓其他線程去搶資源。（注意：在程序中並不是使用 Thread.sleep(10)之後,程序才出現問題,而是使用之後,問題更明顯.）

為什麼會出現這樣的錯誤呢？

先來分析第一種錯誤：為什麼會吃重複的蘋果呢？就拿 B 和 C 都吃了編號為 47 的蘋果為例吧：

• A 線程拿到了編號為 48 的蘋果，打印輸出然後讓 num 減 1，睡眠 10 ms，此時 num 為 47。
• 這時 B 和 C 同時都拿到了編號為 47 的蘋果，打印輸出，在其中一個線程作出了減一操作的時候，A 線程從睡眠中醒過來，拿到了編號為 46 的蘋果，然後輸出。在這期間並沒有任何操作不允許 B 和 C 線程不能拿到同一個編號的蘋果，之前沒有明顯的錯誤僅僅可能只是因為運行速度太快了。

再來分析第二種錯誤：照理來說只應該存在 1-50 編號的蘋果，可是 0 和-1 是怎麼出現的呢？

• 當 num = 1 的時候，A，B，C 三個線程同時進入了 try 語句進行睡眠。
• C 線程先醒過來，輸出了編號為 1 的蘋果，然後讓 num 減一，當 C 線程醒過來的時候發現 num 為 0 了。
• A 線程醒過來一看，0 都沒有了，只有 -1 了。

歸根結底是因為沒有任何操作來限制線程來獲取相同的資源並對他們進行操作，這就造成了線程安全性問題。

如果我們把打印和減一的操作分成兩個步驟，會更加明顯：

ABC 三個線程同時打印了 50 的蘋果，然後同時做出減一操作。

像這樣的原子操作，是不允許分步驟進行的，必須保證同步進行，不然可能會引發不可設想的後果。

要解決上述多線程併發訪問一個資源的安全性問題，就需要引入線程同步的概念。

線程同步

多個執行線程共享一個資源的情景，是最常見的併發編程情景之一。為了解決訪問共享資源錯誤或數據不一致的問題，人們引入了臨界區的概念：用以訪問共享資源的代碼塊，這個代碼塊在同一時間內只允許一個線程執行。

為了幫助編程人員實現這個臨界區，Java（以及大多數編程語言）提供了同步機制，當一個線程試圖訪問一個臨界區時，它將使用一種同步機制來查看是不是已經有其他線程進入臨界區。如果沒有其他線程進入臨界區，他就可以進入臨界區。如果已經有線程進入了臨界區，它就被同步機制掛起，直到進入的線程離開這個臨界區。如果在等待進入臨界區的線程不止一個，JVM 會選擇其中的一個，其餘的將繼續等待。

synchronized 關鍵字

如果一個對象已用 synchronized 關鍵字聲明，那麼只有一個執行線程被允許訪問它。使用 synchronized 的好處顯而易見：保證了多線程併發訪問時的同步操作，避免線程的安全性問題。但是壞處是：使用 synchronized 的方法/代碼塊的性能比不用要低一些。所以好的做法是：盡量減小 synchronized 的作用域。

我們還是先來解決吃蘋果的問題，考慮一下 synchronized 關鍵字應該加在哪裡呢？

發現如果還再把 synchronized 關鍵字加在 if 裏面的話，0 和 -1 又會出來了。這其實是因為當 ABC 同是進入到 if 語句中，等待臨界區釋放的時，拿到 1 編號的線程已經又把 num 減一操作了，而此時最後一個等待臨界區的進程拿到的就會是 -1 了。

同步鎖 Lock

Lock 機制提供了比 synchronized 代碼塊和 synchronized 方法更廣泛的鎖定操作，同步代碼塊/ 同步方法具有的功能 Lock 都有，除此之外更強大，更體現面向對象。在併發包的類族中，Lock 是 JUC 包的頂層接口，它的實現邏輯並未用到 synchronized，而是利用了 volatile 的可見性。

使用 Lock 最典型的代碼如下：

class X {

    private final ReentrantLock lock = new ReentrantLock();

    public void m() {
        lock.lock();
        try {
            // ..... method body
        } finally {
            lock.unlock();
        }
    }
}

線程安全問題

線程安全問題只在多線程環境下才會出現，單線程串行執行不存在此類問題。保證高併發場景下的線程安全，可以從以下四個維度考量：

維度一：數據單線程可見

單線程總是安全的。通過限制數據僅在單線程內可見，可以避免數據被其他線程篡改。最典型的就是線程局部變量，它存儲在獨立虛擬機棧幀的局部變量表中，與其他線程毫無瓜葛。TreadLocal 就是採用這種方式來實現線程安全的。

維度二：只讀對象

只讀對象總是安全的。它的特性是允許複製、拒絕寫入。最典型的只讀對象有 String、Integer 等。一個對象想要拒絕任何寫入，必須要滿足以下條件：

• 使用 final 關鍵字修飾類，避免被繼承；
• 使用 private final 關鍵字避免屬性被中途修改；
• 沒有任何更新方法；
• 返回值不能為可變對象。

維度三：線程安全類

某些線程安全類的內部有非常明確的線程安全機制。比如 StringBuffer 就是一個線程安全類，它採用 synchronized 關鍵字來修飾相關方法。

維度四：同步與鎖機制

如果想要對某個對象進行併發更新操作，但又不屬於上述三類，需要開發工程師在代碼中實現安全的同步機制。雖然這個機制支持的併發場景很有價值，但非常複雜且容易出現問題。

處理線程安全的核心理念

要麼只讀，要麼加鎖。

合理利用好 JDK 提供的併發包，往往能化腐朽為神奇。Java 併發包（java.util.concurrent，JUC）中大多數類註釋都寫有：@author Doug Lea。如果說 Java 是一本史書，那麼 Doug Lea 絕對是開疆拓土的偉大人物。Doug Lea 在當大學老師時，專攻併發編程和併發數據結構設計，主導設計了 JUC 併發包，提高了 Java 併發編程的易用性，大大推進了 Java 的商用進程。

參考資料

• 《Java 零基礎入門教程》 –
• 《Java 併發編程的藝術》
• 《Java 7 併發編程實戰手冊》
• 《碼出高效 Java 開發手冊》 – 楊冠寶（孤盡） 高海慧（鳴莎）著

按照慣例黏一個尾巴：

歡迎轉載，轉載請註明出處！
獨立域名博客：wmyskxz.com
簡書 ID：
github：
歡迎關注公眾微信號：wmyskxz
分享自己的學習 & 學習資料 & 生活
想要交流的朋友也可以加 qq 群：3382693

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!