如果把互聯網上的紛繁代碼比作一片海洋，那麼git就是在這片海洋上航行的船隻，正所謂“水可載舟，亦可覆舟”，git使用恰當可以遠征星辰，不然可能會墜入無窮無盡的代碼海洋無法自拔。書回正傳，我們的征途是星辰大海！

揚帆起航

git的下載安裝暫且不表，可參考網站https://git-scm.com/downloads。

git的安裝只是個入門條件，下面如何使用git命令控制代碼才是遠征的基礎。那麼從何開始呢？讓我們一步步說起。

要想揚帆起航，首先得有艘帆船吧。我們要在本地建立一個項目，之後將本地項目初始化為git倉庫，可以使用

git init [–bare]

初始化本地項目，執行後會在當前執行目錄下生成.git文件夾，這也就是我們的帆船了。[–bare]可選參數，可初始化裸倉庫，裸倉庫可以與源碼項目分離，此時在當前目錄下不會生成.git文件夾，而是直接生成.git文件夾下的包括hooks、info、objects、refs共四個文件夾和config、description、HEAD三個文件。

在初始化裸倉庫后若想關聯源碼，只需進入hooks目錄新建post-receive.sample文件，並添加如下內容：

git –work-tree=<project-dir> –git-dir=<local-url> checkout -f

其中<project-dir>為本地項目文件路徑，<local-url>為本地git倉庫路徑。

 

對於當前目錄下的.git文件夾所代表的本地倉庫，不同的帆船有不同的配置，我們使用

git config –list

显示當前git配置。如果內容過多可以使用上下鍵翻頁，查看結束按q退出即可。同時使用

git config –e [–global]

以vim形式編輯修改git配置文件。

或

git config [–global] user.name “name”

形式修改指定配置，其中[–global]可選，為全局配置，name為用戶名配置。

 

 

git儀錶盤

 

 

 

 

 

 

 

圖 1 Git指令關係圖

 

建立git倉庫作為帆船后，就可以在當前目錄下任意使用git指令遨遊了。我們需要先認識下git控制的命令儀錶盤。

如圖1所示，git整艘船主要分為四大區域，包括Remote遠程倉庫，Repository本地倉庫，Index/Stage暫存區，Workspace工作區，不同區域之間可以使用相關指令進行代碼操作。在上節使用git init創建的文件夾下，會生成名為.git的隱藏文件夾，四大區域的配置都儲存在該文件夾下。其中在遠程倉庫和本地倉庫中，儲存有不同的branch分支，工作區和暫存區的文件只能針對某一分支進行修改提交操作，當然也可以使用分支操作指令對不同的分支進行增刪合併等操作。

針對一些倉庫的操作指令，使用前請務必保持頭腦清醒，不然你的一個蝴蝶煽動翅膀似的操作，可能會引發倉庫里的一場代碼風暴，造成不可挽回的結果。

根據不同命令操作區域，可以將git命令大致分為全局显示信息、工作區與遠程倉庫交互、工作區與本地倉庫交互、工作區與暫存區交互、暫存區與本地倉庫交互、本地倉庫與遠程倉庫交互、以及倉庫內部分支操作。下面對這些命令進行了粗略的統計介紹，詳細使用方式可參考git官方文檔介紹，如有不足還請補充。

显示信息

git help [command]

獲取命令的幫助信息。

 

git status

显示所有變更文件

 

git log [–stat] [–graph]

显示當前分支的版本信息。[–stat]參數指定显示commit發生變更的文件。[–graph]參數以數據圖形式查看合併分支記錄。

 

git blame <file>

显示文件的每一行最後修改的版本和作者

 

git show [commit][:filename]

显示某次提交的變更內容。其中[commit]為某次提交版本，也可在:後邊加參數[filename]指定查看某個文件內容。

 

git diff [HEAD] [first-branch] [second-branch]

显示文件差異。無參時比較緩存區和上一次commit的差異；[HEAD]為工作區與當前分支最新commit的差異；或者兩個分支之間的差異。

 

git reflog

显示已執行過的所有git動作日誌。

 

工作區與遠程倉庫

git pull <remote> <branch>

拉取遠程倉庫的變化，並與本地分支合併。<remote>為遠程倉庫名，<branch>為遠程倉庫中的某一分支名。

工作區與本地倉庫

git checkout [–b] <branch> [tag]

將暫存區切換到分支名。其中[-b]參數可選，當分支不存在時則創建，<branch >必須，為本地倉庫分支，[tag]可選，指定切換到倉庫分支中的某條標籤，不標註則默認為切換分支的最近一次提交。

工作區與暫存區

git add <dir>

添加指定目錄到暫存區，<dir>為添加路徑，允許多個，包括子目錄都會添加到暫存區中等待提交。

 

git rm [–cached] <file>

刪除暫存區中的文件，<file>為暫存區中要刪除的文件全路徑，[–cache]可選參數，只會停止繼續追蹤指定文件，但該文件目前仍然保留在暫存區。

 

git mv <file-old> <file-new>

修改暫存區中的文件名，<file-old>為原文件全路徑，<file-new>為修改后的文件全路徑。

 

 

git tag

查看暫存區中的所有標籤信息。

 

git tag –a <tag> [commit]

新建一個標籤。[tag]為標籤名；[commit]為指定的一次從暫存區到本地倉庫的提交中，默認為最新一次提交。

 

git tag –d [tag]

刪除本地標籤。

暫存區與本地倉庫

git commit [–amend] [–m <message>] [file] [-a] [-v]

從暫存區提交到本地倉庫。其中[–amend]重做上次從本地項目到暫存區的commit，當代碼與上次提交相比無變化時使用，只修改上次commit的<message>內容；[-m]參數為提交信息，<message>必寫且詳寫，以區別提交代碼的修改內容；[file]為指定暫存區中的文件；[-a]可直接提交項目中的變化到本地倉庫，在沒有新增文件時不需每次先git add提交到暫存區再提交到本地倉庫；[-v]可以在提交時显示所有變化文件的diff信息。

 

git cherry-pick [commit]

選擇一個commit版本合併到當前分支，[commit]為暫存區中的commit版本。

 

本地倉庫與遠程倉庫

git remote [-v]

查看關聯的遠程倉庫信息。[-v]可以查看詳細信息。

 

git remote add <remote-name> <remote-url>

本地路徑關聯遠程倉庫。

<remote-name>必要參數，為遠程倉庫的名字，默認是origin。

<remote-url>必要參數，為遠程倉庫的地址，git服務器通常都是以.git結尾。

 

git remote remove <remote-name>

刪除關聯的遠程倉庫。其中<remote-name>為遠程倉庫的名字。

 

git push [remote] [branch] [–force]

推送本地指定分支到遠程倉庫。[remote]為遠程倉庫名，[branch]為本地分支名，[–force]為強制推送本地到遠程，如有衝突則覆蓋。

 

git fetch <remote>

將遠程倉庫拉到本地倉庫。<remote>為遠程倉庫名。

 

git clone <url> [name]

創建一個本地倉庫。<url>必須，可以是遠程git服務器上的倉庫，也可以是本地倉庫。[name]選填是創建的新倉庫名，默認與原倉庫名一致。

 

分支指令

git branch [-r] [-a]

查看分支信息，無參只會查看本地倉庫所有分支，[-r]是遠程倉庫所有分支，[-a]則是包括本地和遠程倉庫所有的所有分支。

git branch [branch-name] [commit]

在本地倉庫新建分支，但暫存區仍然指向當前分支。其中[branch-name]為新建的本地倉庫分支；[commit]可將分支指向指定commit版本。

 

git branch –track [local-branch-name] [remote-branch]

新建一個分支，並連接指定的遠程分支。其中[local-branch-name]為本地倉庫新建分支，[remote-branch]為遠程倉庫分支。

 

git branch –set-upstream [local-branch] [remote-branch]

連接本地倉庫分支與遠程倉庫分支，其中[local-branch]為本地倉庫已有分支，[remote-branch]為遠程倉庫分支。

 

git branch –d [branch]

刪除本地倉庫分支，[branch]為本地倉庫中的已有分支。

 

git branch -m [branch-old] [branch-new]

修改本地倉庫分支，其中[branch-old]為原分支，[branch-new]為改名后的分支。

 

git branch –dr [remote-branch]

刪除遠程倉庫分支，[remote-branch]為遠程倉庫中的分支。不推薦使用，如果遠程倉庫未更新，可能會執行失敗，推薦使用git push origin-delete [remote-branch]。

 

git merge <local-branch>

合併指定分支到當前分支，<local-branch>為本地倉庫中的已有分支。

 

git rebase <remote-branch>

將當前分支的提交複製到指定的遠程分支上，<remote-branch>為指定遠程倉庫中的已有分支。

 

git reset [–mixed|–soft|–hard] [commit]

重置倉庫索引，重置一旦清空后的內容不會在倉庫歷史版本中留下歷史記錄。[–mixed]為默認參數，重置后只在工作區保留原節點修改文件，清空暫存區和本地倉庫並均恢復到指定重置節點；[–soft]為軟重置，重置后在工作區和暫存區均保留原節點修改文件，清空本地倉庫並恢復到指定重置節點；[–hard]為硬重置，重置后均不會保留原節點修改文件。[commit]為要重置的節點號。

 

git revert [commit]

還原文件到之前修改提交節點時，會在倉庫歷史版本中留下歷史記錄。[commit]為要還原的節點號。

常規操作

git這艘大船雖然功能繁雜，但是用起來是有章可循的。入門之後就駕駛下這艘大船來試試吧。

一般git有三種工作流程，包括Git flow，項目存在兩個長期分支（主分支master和開發分支develop），適用於基於版本發布的普通項目；Github flow，只有一個長期分支（主分支master），適用於持續發布的小型項目；Gitlab flow，項目存在多個長期分支，其中主分支master是其他所有分支的上游，只有上游分支採納的代碼才能應用到其下游分支，適用於長期維護的大型項目。

圖2展示了一次項目git流程演變過程，在master主分支上有Tag1-Tag4四次代碼更新，其中基於Tag2對應的版本1號創建了新的branch1分支，新分支創建后自動生成了版本2號並打上了Tag2-1標籤，之後master主分支和branch1分支都同時進行了代碼演變，在branch1分支提交的版本4號及標籤Tag2-3之後，branch1分支合併到了master主分支，合併前master主分支位於版本5號，合併后可能重新生成版本6號，並打上新的tag4標籤，之後master主分支修改提交為版本7號，而branch1分支則停留在tag2-3標籤的位置處。

 

 

 

 

 圖 2 Git流程示意圖

 

在這份項目流程中，分支創建之後，可能在不同的階段修改提交文件，根據對文檔的讀取權限範圍，我們可以形象地將這些階段劃分為三種身份類型，船長、水手和遊客。船長身份，作為項目管理者，主要負責遠程倉庫和本地倉庫之間的分支操作，協調分支衝突；水手身份，作為項目貢獻者，主要負責某一分支的迭代更新；遊客身份，作為項目使用者，只是訪問使用倉庫及其分支內容，不能提交任何修改。同一人在項目的不同階段可以是其中任意一種身份，下面以這三種身份為維度簡單介紹下使用到的相關git指令步驟，並輔以示意圖方式直觀解釋git指令執行前後git項目變化。

 

 

項目使用者-遊客

        作為git項目的遊客，當然只能將項目從遠程倉庫拉取到本地使用，期間除了切換倉庫分支外不會涉及其他遠程操作。

 

git pull origin master

拉取遠程倉庫origin的master分支到本地。

 

git checkout branch1 tag1

切換到分支branch1。

 

 

項目貢獻者-水手

        作為項目的水手，除了可以使用遊客的功能指令外，還會涉及到修改工作區文件，並將工作區文件提交到暫存區和倉庫等任務。通常水手只需要維護倉庫中的某一條分支並只對該分支負責，因此水手更注重工作區的代碼文件修改工作。

 

git pull origin dev:branch1

拉取遠程倉庫origin的dev分支到本地，並與本地branch1分支合併。工作區中文件即显示branch1分支，可在工作區做文件修改操作。

 

git add .

在工作區的文件修改之後，可先添加當前目錄所有文件到暫存區，之後可繼續修改工作區其他文件，也可將暫存區文件提交到本地倉庫。

 

git rm –cached file

針對工作區編譯生成的配置file文件，一般不需提交到倉庫，可使用該命令將file文件從暫存區刪除並停止後續追蹤。另外一種添加忽略文件的方式，在.git文件夾的同級目錄下新建.gitignore文件，在該文件中根據規則增加要忽略的文件路徑，之後將該文件提交到本地倉庫中。

 

git commit –m “commit message 1”

在確保工作區的所有修改文件均已提交到暫存區后，便將暫存區的修改提交到本地倉庫，同時附帶當次提交信息。每次提交都會在本地倉庫生成一個新的提交commit版本號，由於提交的commit版本號是冗長的sha1碼，所以為了方便後期溯源，通常會在主要的commit號版本上再打一個鮮明的標籤以作標記。

 

 

 

git tag tag1 1

在提交的commit版本號為1的節點上打標籤，打上標籤后的commit號便可使用簡短的標籤名tag1訪問，以便後期對該節點溯源。

 

 

 

git push origin branch1:dev –tags

將本地branch1分支及相關標籤推送到遠程倉庫origin的dev分支。如果本地branch1分支已經與遠程dev分支建立追蹤關係，也可直接使用

git push origin branch1 –tags

指令。

 

git branch –set-upstream-to=origin/dev branch1

設置本地倉庫的branch1分支與遠程倉庫origin的dev分支的追蹤關係。通常從遠程分支pull到本地的分支都已經建立了追蹤關係，不需要手動修改。

 

git branch –vv

查看本地分支及追蹤的遠程分支信息。

 

項目管理者-船長

        作為項目的船長，自然擁有整個git這艘大船的項目所有權限，除了使用水手的操作指令外，另需完成分支增刪合併等任務。通常船長是項目倉庫的創建者，負責管理維護倉庫的各分支關係，對項目的整個倉庫負責，因此相較於水手，船長更注重倉庫的分支管理相關工作。

 

git clone https://github.com/xxx.git -b dev

克隆遠程倉庫的dev分支到本地，默認會將文件更新到本地倉庫建立的同名dev分支。

 

git checkout –b branch1 origin/dev

在本地倉庫新建branch1分支，與遠程倉庫origin中的dev分支對應，並在本地切換到branch1分支。如果不指定遠程倉庫及分支信息origin/dev，則默認從本地倉庫dev分支創建。至此可以切換為水手身份，從該分支更新代碼，並將修改文件提交到該branch1分支。

 

git add .

git commit –m “modify file commit”

在完成對工作區文件的修改之後，使用水手身份將工作區的修改提交到本地branch1分支。

 

git checkout dev

切換到本地倉庫的dev主分支，作為本地倉庫與遠程倉庫代碼合併的操作分支。

 

git fetch origin dev

拉取遠程倉庫origin中的dev分支到本地倉庫當前dev分支

 

git pull

將本地倉庫dev分支的文件修改合併到工作區。

 

git merge branch1

將本地倉庫的branch1分支合併到當前dev分支。如果當前dev分支與branch1分支有衝突，需要根據衝突文件提示分別修改，之後再重新合併該分支。

 

git checkout branch1 build/files

或者只將branch1分支的build/files目錄下所有文件合併到本地倉庫的當前dev分支。同樣需要做衝突處理。

 

git push origin dev:dev –tags

向遠程倉庫origin中的dev分支並推送本地倉庫dev分支。推送時如果確認以本地分支覆蓋遠程分支，則可使用

 

git push —force origin dev:dev –tags

強制推送。最後如果想刪除遠程分支，有以下兩條指令

 

git push origin –delete dev

git push origin :dev

這兩種方式都可以刪除指定的遠程倉庫origin中的dev分支。

 

應急預案

上面的圖2Git流程圖簡單涉及了一次版本演變過程中的一些git信息，包括分支切換，打標籤等，看上去簡單易懂，而實際我們工作中駕船航行時卻並不總是風平浪靜。

        通常出現的緊急情況需要修改分支版本，包括變基、還原、重置等操作，針對不同場景需要選擇不同的操作方式。

變基

git rebase master

變基會將當前分支的修改文件複製到master分支，同時創建新的commit版本號並修改項目的歷史記錄。當master分支已經更新，且確認當前分支與master分支沒有衝突，那可以使用變基以便當前分支獲取master分支的更新。

 

 

 

 

重置

git reset 1

將HEAD重置到歷史提交版本1的狀態，還原倉庫和暫存區的文件與提交版本1一致，工作區維持修改文件狀態。

 

 

 

 

還原

 

git revert 1

重新創建一次提交版本節點，文件狀態與歷史提交版本1一致，工作區、暫存區與倉庫均保持一致。提交版本2相對於提交版本1新增了file.txt文件，執行該指令后，在提交版本3中將恢復到提交版本1的狀態，因此提交版本3相對於提交版本2則刪除了file.txt文件。

 

 

強制遠程覆蓋本地

git fetch –all

拉取遠程所有倉庫到本地倉庫，工作區不會有任何合併更新。

 

git reset –hard origin/dev

把工作區HEAD指向最新的遠程倉庫origin中的dev版本。

待補充

除此之外在駕馭git這艘大船時肯定還會出現各種意外，屆時將酌情補充。

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

這是why的第 53 篇原創文章

荒腔走板

大家好，我是why。

時間過的真是快，一周又要結束了。那麼，你比上周更博學了嗎？先來一個簡短的荒腔走板，給冰冷的技術文注入一絲色彩。

上面這圖是我之前拼的一副拼圖，一共劃分了800塊，背面無提示，難度極高，我花了兩周的時間才拼完。

拼的是壇城，傳說中佛祖居住生活的地方。

第一次知道這個名詞是 2015 年，窩在寢室看紀錄片《第三極》。

其中有一個片段講的就是僧人為了某個節日用沙繪畫壇城，他們的那種專註，虔誠，真摯深深的打動了我，當宏偉的壇城畫完之後，他靜靜的等待節日的到來。

本以為節日當天眾人會對壇城頂禮膜拜，而實際情況是大家手握一炷香，看着眾僧人快速的摧毀壇城。

還沒來得及仔細欣賞那複雜的美麗的圖案，卻又用掃把掃的乾乾凈凈。

掃把掃下去的那一瞬間，我的心受到了一種強烈的撞擊：可以辛苦地拿起，也可以輕鬆地放下。

看到摧毀壇城的片段的時候，有一個彈幕是這樣說的：

一切有為法，如夢幻泡影，如露亦如電，應作如是觀。

這句話出自《金剛般若波羅蜜經》第三十二品，應化非真分。

因為之前翻閱過幾次《金剛經》，看到這句話的時候我一下就想起了它。

因為讀的時候我就覺得這句話很有哲理，但是也似懂非懂。所以印象比較深刻。

當他再次在壇城這個畫面上以彈幕的形式展現在我的眼前的時候，我一下就懂了其中的哲理，不敢說大徹大悟，至少領悟一二。

觀看摧毀壇城，這個色彩斑斕的世界變幻消失的過程，正常人的感受都是震撼，轉而覺得可惜，心裏久久不能平靜。

但是僧人卻風輕雲淡的說：一切有為法，如夢幻泡影，如露亦如電，應作如是觀。

好了，說迴文章。

先說AtomicLong

關於 AtomicLong 我就不進行詳細的介紹了。

先寫這一小節的目的是預熱一下，拋出一個問題，而這個問題是關於 CAS 操作和 volatile 關鍵字的。

我不知道源碼為什麼這樣寫，希望知道答案的朋友指點一二。

抱拳了，老鐵。

為了順利的拋出這個問題，我就得先用《Java併發編程的藝術》一書做引子，引出這個問題。

首先在書的第 2.3 章節《原子操作的實現原理》中介紹處理器是如何實現原子操作時提到了兩點：

• 使用總線鎖保證原子性。

• 使用緩存鎖保證原子性。

所謂總線鎖就是使用處理器提供一個提供的一個 LOCK # 信號，當一個處理器在總線上輸出此信號時，其他處理器的請求將被阻塞住，那麼該處理器可以獨佔共享內存。

總線鎖保證原子性的操作有點簡單粗暴直接了，導致總線鎖定的開銷比較大。

所以，目前處理器在某些場合下使用緩存鎖來進行優化。

緩存鎖的概念可以看一下書裏面怎麼寫的：

其中提到的圖 2-3 是這樣的：

其實關鍵 Lock 前綴指令。

被 Lock 前綴指令操作的內存區域就會加鎖，導致其他處理器不能同時訪問。

而根據 IA-32 架構軟件開發者手冊可以知道，Lock 前綴的指令在多核處理器下會引發兩件事情：

• 將當前處理器緩存行的數據寫回系統內存。
• 這個寫回內存的操作會使在其他 CPU 里緩存了該內存地址的數據無效。

對於 volatile 關鍵字，毫無疑問，我們是知道它是使用了 Lock 前綴指令的。

那麼問題來了，JVM 的 CAS 操作使用了 Lock 前綴指令嗎？

是的，使用了。

JVM 中的 CAS 操作使用的是處理器通過的 CMPXCHG 指令實現的。這也是一個 Lock 前綴指令。

好，接下來我們看一個方法：

java.util.concurrent.locks.AbstractQueuedLongSynchronizer#compareAndSetState

這個方法位於 AQS 包裏面，就是一個 CAS 的操作。現在只需要關心我框起來的部分。

英文部分翻譯過來是：這個操作具有 volatile 讀和寫的內存語言。

而這個操作是什麼操作？

就是 344 行 unsafe 的 compareAndSwapLong 操作，這個方法是一個 native 方法。

public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

為什麼這個操作具有 volatile 讀和寫的內存語言呢？

書裏面是這樣寫的：

這個本地方法的最終實現在 openjdk 的如下位置：
openjdk-7-fcs-src-b147- 27_jun_2011\openjdk\hotspot\src\os_cpu\windows_x86\vm\atomic_windows_x86.inline.hpp（對應於Windows操作系統，X86處理器）

intel 的手冊對 Lock 前綴的說明如下。

• 確保對內存的讀-改-寫操作原子執行。在 Pentium 及 Pentium 之前的處理器中，帶有 Lock 前綴的指令在執行期間會鎖住總線，使得其他處理器暫時無法通過總線訪問內存。很顯然，這會帶來昂貴的開銷。從Pentium 4、Intel Xeon及P6處理器開始，Intel使用緩存鎖定（Cache Locking） 來保證指令執行的原子性。緩存鎖定將大大降低lock前綴指令的執行開銷。

• 禁止該指令，與之前和之後的讀和寫指令重排序。

• 把寫緩衝區中的所有數據刷新到內存中。

上面的第2點和第3點所具有的內存屏障效果，足以同時實現 volatile 讀和volatile 寫的內存語義。

好，如果你說你對書上的內容存疑。那麼我帶大家再看看官方文檔：

https://docs.oracle.com/javase/8/docs/api/

我框起來的部分：

compareAndSet 和所有其他的諸如 getAndIncrement 這種讀然後更新的操作擁有和 volatile 讀、寫一樣的內存語義。

原因就是用的到了 Lock 指令。

好，到這裏我們可以得出結論了：

compareAndSet 同時具有volatile讀和volatile寫的內存語義。

那麼問題就來了！

這個操作，在 AtomicLong 裏面也有調用：

而 AtomicLong 裏面的 value 又是被 volatile 修飾了的：

請問：為什麼 compareAndSwapLong 操作已經同時具有 volatile 讀和 volatile 寫的內存語義了，其操作的 value 還需要被 volatile 修飾呢？

這個問題也是一個朋友拋出來探討的，探討的結果是，我們都不知道為什麼：

我猜測會不會是由於操作系統不同而不同。在 x86 上面運行是這樣，其他的操作系統就不一定了，但是沒有證據。

希望知道為什麼這樣做的朋友能指點一下。

好，那麼前面說到 CAS ，那麼一個經典的面試題就來了：

請問，CAS 實現原子操作有哪些問題呢？

• ABA問題。

• 循環時間開銷大。

• 只能保證一個共享變量的原子操作。

如果上面這三點你不知道，或者你說不明白，那我建議你看完本文後一定去了解一下，屬於面試常問系列。

我主要說說這個循環時間開銷大的問題。自旋 CAS 如果長時間不成功，就會對 CPU 帶來比較大的執行開銷。

而回答這個問題的朋友，大多數舉例的時候都會說： “AtomicLong 就是基於自旋 CAS 做的，會帶來一定的性能問題。巴拉巴拉……”

而我作為面試官的時候只是微笑着看着你，讓你錯以為自己答的很完美。

我知道你為什麼這樣答，因為你看了幾篇博客，刷了刷常見面試題，那裡面都是這樣寫的 ：AtomicLong 就是基於自旋 CAS 做的。

但是，朋友，你可以這樣說，但是回答不完美。這題得分別從 JDK 7 和 JDK 8 去答：

JDK 7 的 AtomicLong 是基於自旋 CAS 做的，比如下面這個方法：

while(true) 就是自旋，自旋裏面純粹依賴於 compareAndSet 方法：

這個方法裏面調用的 native 的 comareAndSwapLong 方法，對應的 Lock 前綴指令就是我們前面說到的 cmpxchg。

而在 JDK 8 裏面 AtomicLong 裏面的一些方法也是自旋，但是就不僅僅依賴於 cmpxchg 指令做了，比如還是上面這個方法：

可以看到這裏面還是有一個 do-while 的循環，還是調用的 compareAndSwapLong 方法：

這個方法對應的 Lock 前綴指令是我們前面提到過的 xadd 指令。

從 Java 代碼的角度來看，都是自旋，都是 compareAndSwapLong 方法。沒有什麼差異。

但是從這篇 oracle 官網的文章，我們可以窺見 JDK 8 在 x86 平台上對 compareAndSwapLong 方法做了一些操作，使用了 xadd 彙編指令代替 CAS 操作。

xadd 指令是 fetch and add。

cmpxchg 指令是 compare and swap。

xadd 指令的性能是優於 cmpxchg 指令的。

具體可以看看這篇 oracle 官網的文章：

https://blogs.oracle.com/dave/atomic-fetch-and-add-vs-compare-and-swap

文章下面的評論，可以多注意一下，我截取其中兩個，大家品一品：

然後是這個：

總之就是：這篇文章說的有道理，我們（Dave and Doug）也在思考這個問題。所以我們會在 JIT 上面搞事情，在 x86 平台上把 CAS 操作替換為 LOCK:XADD 指令。

（這個地方我之前理解的有問題，經過朋友的指正後才修改過來。）

所以，JDK 8 之後的 AtomicLong 裏面的方法都是經過改良后， xadd+cmpxchg 雙重加持的方法。

另外需要注意的是，我怕有的朋友懵逼，專門多提一嘴：CAS 是指一次比較並交換的過程，成功了就返回 true，失敗了則返回 false，強調的是一次。而自旋 CAS 是在死循環裏面進行比較並交換，只要不返回 true 就一直循環。

所以，不要一提到 CAS 就說循環時間開銷大。前面記得加上“自旋”和“競爭大”兩個條件。

至於 JDK 8 使用 xadd 彙編指令代替 CAS 操作的是否真的是性能更好了，可以看看這篇 oracle 官網的文章：

https://blogs.oracle.com/dave/atomic-fetch-and-add-vs-compare-and-swap

文章下面的評論，可以多注意一下，我截取其中一個，大家品一品：

經過我們前面的分析，AtomicLong 從 JDK 7 到 JDK 8 是有一定程度上的性能優化的，但是改動並不大。

還是存在一個問題：雖然它可以實現原子性的增減操作，但是當競爭非常大的時候，被操作的這個 value 就是一個熱點數據，所有線程都要去對其進行爭搶，導致併發修改時衝突很大。

所以，歸根到底它的主要問題還是出在共享熱點數據上。

為了解決這個問題，Doug Lea 在 JDK 8 裏面引入了 LongAdder 類。

更加牛逼的LongAdder

大家先看一下官網上的介紹：

上面的截圖一共兩段話，是對 LongAdder 的簡介，我給大家翻譯並解讀一下。

首先第一段：當有多線程競爭的情況下，有個叫做變量集合（set of variables）的東西會動態的增加，以減少競爭。sum() 方法返回的是某個時刻的這些變量的總和。

所以，我們知道了它的返回值，不論是 sum() 方法還是 longValue() 方法，都是那個時刻的，不是一個準確的值。

意思就是你拿到這個值的那一刻，這個值其實已經變了。

這點是非常重要的，為什麼會是這樣呢？

我們對比一下 AtomicLong 和 LongAdder 的自增方法就可以知道了：

AtomicLong 的自增是有返回值的，就是一個這次調用之後的準確的值，這是一個原子性的操作。

LongAdder 的自增是沒有返回值的，你要獲取當前值的時候，只能調用 sum 方法。

你想這個操作：先自增，再獲取值，這就不是原子操作了。

所以，當多線程併發調用的時候，sum 方法返回的值必定不是一個準確的值。除非你加鎖。

該方法上的說明也是這樣的：

至於為什麼不能返回一個準確的值，這就是和它的設計相關了，這點放在後面去說。

然後第二段：當在多線程的情況下對一個共享數據進行更新（寫）操作，比如實現一些統計信息類的需求，LongAdder 的表現比它的老大哥 AtomicLong 表現的更好。在併發不高的時候，兩個類都差不多。但是高併發時 LongAdder 的吞吐量明顯高一點，它也佔用更多的空間。這是一種空間換時間的思想。

這段話其實是接着第一段話在進行描述的。

因為它在多線程併發情況下，沒有一個準確的返回值，所以當你需要根據返回值去搞事情的時候，你就要仔細思考思考，這個返回值你是要精準的，還是大概的統計類的數據就行。

比如說，如果你是用來做序號生成器，所以你需要一個準確的返回值，那麼還是用 AtomicLong 更加合適。

如果你是用來做計數器，這種寫多讀少的場景。比如接口訪問次數的統計類需求，不需要時時刻刻的返回一個準確的值，那就上 LongAdder 吧。

總之，AtomicLong 是可以保證每次都有準確值，而 LongAdder 是可以保證最終數據是準確的。高併發的場景下 LongAdder 的寫性能比 AtomicLong 高。

接下來探討三個問題：

• LongAdder 是怎麼解決多線程操作熱點 value 導致併發修改衝突很大這個問題的？

• 為什麼高併發場景下 LongAdder 的 sum 方法不能返回一個準確的值？

• 為什麼高併發場景下 LongAdder 的寫性能比 AtomicLong 高？

先帶大家看個圖片，看不懂沒有關係，先有個大概的印象：

接下來我們就去探索源碼，源碼之下無秘密。

從源碼我們可以看到 add 方法是關鍵：

裏面有 cells 、base 這樣的變量，所以在解釋 add 方法之前，我們先看一下 這幾個成員變量。

這幾個變量是 Striped64 裏面的。

LongAdder 是 Striped64 的子類：

其中的四個變量如下：

• NCPU：cpu 的個數，用來決定 cells 數組的大小。

• cells：一個數組，當不為 null 的時候大小是 2 的次冪。裏面放的是 cell 對象。

• base : 基數值，當沒有競爭的時候直接把值累加到 base 裏面。還有一個作用就是在 cells 初始化時，由於 cells 只能初始化一次，所以其他競爭初始化操作失敗線程會把值累加到 base 裏面。

• cellsBusy：當 cells 在擴容或者初始化的時候的鎖標識。

之前，文檔裏面說的 set of variables 就是這裏的 cells。

好了，我們再回到 add 方法裏面：

cells 沒有被初始化過，說明是第一次調用或者競爭不大，導致 CAS 操作每次都是成功的。

casBase 方法就是進行 CAS 操作。

當由於競爭激烈導致 casBase 方法返回了 false 后，進入 if 分支判斷。

這個 if 分子判斷有 4 個條件，做了 3 種情況的判斷

• 標號為 ① 的地方是再次判斷 cells 數組是否為 null 或者 size 為 0 。as 就是 cells 數組。

• 標號為 ② 的地方是判斷當前線程對 cells 數組大小取模后的值，在 cells 數組裡面是否能取到 cell 對象。

• 標號為 ③ 的地方是對取到的 cell 對象進行 CAS 操作是否能成功。

這三個操作的含義為：當 cells 數組裡面有東西，並且通過 getProbe() & m算出來的值，在 cells 數組裡面能取到東西（cell）時，就再次對取到的 cell 對象進行 CAS 操作。

如果不滿足上面的條件，則進入 longAccumulate 函數。

這個方法主要是對 cells 數組進行操作，你想一個數組它可以有三個狀態：未初始化、初始化中、已初始化，所以下面就是對這三種狀態的分別處理：

• 標號為 ① 的地方是 cells 已經初始化過了，那麼這個裡面可以進行在 cell 裏面累加的操作，或者擴容的操作。

• 標號為 ② 的地方是 cells 沒有初始化，也還沒有被加鎖，那就對 cellsBusy 標識進行 CAS 操作，嘗試加鎖。加鎖成功了就可以在這裏面進行一些初始化的事情。

• 標號為 ③ 的地方是 cells 正在進行初始化，這個時候就在 base 基數上進行 CAS 的累加操作。

上面三步是在一個死循環裏面的。

所以如果 cells 還沒有進行初始化，由於有鎖的標誌位，所以就算併發非常大的時候一定只有一個線程去做初始化 cells 的操作，然後對 cells 進行初始化或者擴容的時候，其他線程的值就在 base 上進行累加操作。

上面就是 sum 方法的工作過程。

感受到了嗎，其實這就是一個分段操作的思想，不知道你有沒有想到 ConcurrentHashMap，也不奇怪，畢竟這兩個東西都是 Doug Lea 寫的。

然後再補充說明一下，cells 的初始化大小為 2：

cells 的最大值為 CPU 核數：

cell 是被 Contended 註解修飾了，為了解決偽共享的問題：

說起偽共享，我想起了之前的《一個困擾我122天的技術問題，我好像知道答案了》這篇文章中提到的一個猜想：

後來，我也用這個註解去解決偽共享的問題了，可惜最終的實驗結果表明不是這個原因。

那篇文章發布後有很多朋友給我反饋他們的看法，而更多的是在這條路上發現了更多更多的玄學問題，但是最終這些問題的背後都指向了同一個東西：JIT。

扯遠了，說回本文的這個 LongAdder。

總的來說，就是當沒有衝突的時候 LongAdder 表現的和 AtomicLong 一樣。當有衝突的時候，才是 LongAdder 表現的時候，然後我們再回去看這個圖，就能明白怎麼回事了：

好了，現在我們回到前面提出的三個問題：

• LongAdder 是怎麼解決多線程操作熱點 value 導致併發修改衝突很大這個問題的？

• 為什麼高併發場景下 LongAdder 的 sum 方法不能返回一個準確的值？

• 為什麼高併發場景下 LongAdder 的寫性能比 AtomicLong 高？

它們其實是一個問題。

因為 LongAdder 把熱點 value 拆分了，放到了各個 cell 裏面去操作。這樣就相當於把衝突分散到了 cell 裏面。所以解決了併發修改衝突很大這個問題。

當發生衝突時 sum= base+cells。高併發的情況下當你獲取 sum 的時候，cells 極有可能正在被其他的線程改變。一個在高併發場景下實時變化的值，你要它怎麼給你個準確值？當然，你也可以通過加鎖操作拿到當前的一個準確值，但是這種場景你還用啥 LongAdder，是 AtomicLong 不香了嗎？

為什麼高併發場景下 LongAdder 的寫性能比 AtomicLong 高？

你發動你的小腦殼想一想，朋友。

AtomicLong 不管有沒有衝突，它寫的都是一個共享的 value，有衝突的時候它就在自旋。

LongAdder 沒有衝突的時候表現的和 AtomicLong 一樣，有衝突的時候就把衝突分散到各個 cell 裏面了，衝突分散了，寫的當然更快了。

一點思考

本文的題目是《我從LongAdder中窺探到了高併發的秘籍，上面就寫了兩個字……》。

那麼這兩個字是什麼呢？

就是拆分。我淺顯的覺得分佈式、高併發都是基於拆分思想的。

本文的 LongAdder 就不說了。

微服務化、分庫分表、讀寫分離……這些東西都是在拆分，把集中的壓力分散開來。

我們常常說性能不行了，那就堆機器解決，這就是在做拆分。

當然，拆分了帶來好處的同時也是有一定的問題的。

比如老大難的分佈式事務、數據聚合查詢等需求。

舉一個我遇到過的例子吧。

在寫這篇文章之前，我看了 LongAdder 源碼，了解到它這樣的結構后，知道了它和 AtomicLong 之間的差異后，我想起了之前做過的一個需求。

就是賬戶服務，有個大商戶的賬戶是一個熱點賬戶，交易非常的頻繁。

這個賬戶上的金額就相當於是一個共享的熱點數據。

我們當時的做法是把這個賬戶拆分為多個影子賬戶，這樣就把熱點賬戶拆分成了多個影子賬戶，壓力就分攤了。

其實這個思想和 LongAdder 是一脈相承的。

這個場景下拆分帶來的問題是什麼呢？

其中一個問題就是這個賬戶的總餘額是多個影子賬戶之和，而每個影子賬戶上的餘額是時刻在變化的，所以我們不能保證餘額是一個實時準確的值。

但是商戶不關心這個呀。他只關心上日餘額是準確的，每日對賬都能對上就行了。

我們在滿足需求的同時，性能還上去了。

還有一個簡單的思考是如果我們把“實現原子操作進行加減”這句話當做一個需求。

我個人拙見是這樣的，AtomicLong 類就是實現了這個需求，交付出去后，它能用，能正常工作，而且還附送了一個功能是每次都給你返回一個準確的值。

而 LongAdder 就是更加優雅的實現了這個需求，它是在原有的基礎上進行了迭代開發，功能還是能一樣的實現，沒有附加功能，但是針對某些場景來說，更好用了。

它們傳遞給我的思想不是我們常說的：先上，能跑就行，後期再迭代。

而是：它確實能跑，但是還有更加快，更加優雅的實現方式，我們可以實現它。

這是我們需要學習的地方。

最後說兩句（求關注）

才疏學淺，難免會有紕漏，如果你發現了錯誤的地方，還請你留言指出來，我對其加以修改。

感謝您的閱讀，我堅持原創，十分歡迎並感謝您的關注。

我是 why，一個被代碼耽誤的文學創作者，不是大佬，但是喜歡分享，是一個又暖又有料的四川好男人。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!