5個要點，避免踩坑小程序

程序作為產(chǎn)品形態(tài)的一種，比App輕量、比Web網(wǎng)頁簡潔，但由于依賴微信生態(tài)，必須遵守微信生態(tài)的規(guī)則。作為產(chǎn)品經(jīng)理，參與小程序產(chǎn)品迭代已有四個月，踩過不少坑；經(jīng)歷幾次迭代，對小程序規(guī)則有了一定了解。希望在這里能夠總結(jié)小程序這種產(chǎn)品形態(tài)，有哪些注意點。

毫無約束的自由往往無法創(chuàng)新，在一定規(guī)則內(nèi)的自由才是真正的自由。而微信生態(tài)就是小程序必須遵守的規(guī)則，遵守微信的克制，五花八門的小程序一個個冒出頭來，小程序成為追逐線上紅利的絕佳土壤。

小程序的上線流程：

小程序開發(fā)：迭代流程和App產(chǎn)品相同，更加輕量化。要注意的是，每個小程序都有唯一的Appid和Appsecret，后者只有小程序管理員可查看。
開發(fā)版：將代碼上傳微信，可用于開發(fā)大佬測試效果。
體驗版：可通過二維碼分享體驗，需要管理員為微信號添加體驗權(quán)限。
線上版：將體驗版提交微信審核，通過后即可上線正式版小程序，此時可在微信搜索到小程序，審核時間大約半天。

一、小程序一鍵更新

小程序的重啟機制：小程序沒有重啟概念。

「熱啟動」小程序沒有直接銷毀，而是進入后臺狀態(tài)：

點擊右上角膠囊按鈕關(guān)閉小程序；
Home鍵離開小程序。

「冷啟動」小程序需重新加載啟動：

用戶首次打開小程序；
當小程序進入后臺狀態(tài)，超過一定時間（5分鐘），被微信主動銷毀后再次打開；
收到系統(tǒng)內(nèi)存告警，小程序主動銷毀。

這樣就會導(dǎo)致小程序版本更新后，如果客戶端存在舊版本的緩存，那就不會自動升級到新版本，而是維持舊版本的功能；所以需要在版本更新后，前端強制應(yīng)用新版本并重啟。

第三方授權(quán)：作為小程序開發(fā)者，每次版本更新時都需要將代碼包上傳，并提交審核，比較麻煩。公司作為第三方開發(fā)者，例如有贊，可以支持一鍵授權(quán)功能——授權(quán)后的小程序能夠?qū)崿F(xiàn)有新版本時自動提交審核，通過接口將小程序提交審核并發(fā)布，這樣對于同時管理開發(fā)多個小程序的第三方來講，省時省力。

二、小程序跳轉(zhuǎn)類型

1. H5

內(nèi)部H5頁面需要將鏈接配置為業(yè)務(wù)域名。好處是H5更新不需要審核，隨時可部署。弊處是如果該H5用于多個小程序，那么頁面會統(tǒng)一更新；外部H5頁面，如微信商城等，需要將鏈接配置為業(yè)務(wù)域名，并下載校驗文件，將校驗文件添加至該域名的根目錄下。業(yè)務(wù)域名規(guī)則為：每個小程序只能添加20個業(yè)務(wù)域名，一年只可修改50次業(yè)務(wù)域名。

2. 公眾號文章

小程序支持通過<web-view>組件接口打開公眾號文章，該公眾號必須和小程序關(guān)聯(lián)。

參考官方文檔：https://developers.weixin.qq.com/miniprogram/dev/component/web-view.html?search-key=webview

3. 小程序

小程序和小程序之間可實現(xiàn)相互跳轉(zhuǎn)，且無需關(guān)聯(lián)同一公眾號。需獲得小程序的Appid及跳轉(zhuǎn)路徑，限制為每個小程序最多關(guān)聯(lián)10個其他小程序。

參考官方文擋：https://developers.weixin.qq.com/miniprogram/dev/api/wx.navigateToMiniProgram.html

三、推送微信服務(wù)通知

需要對用戶發(fā)送服務(wù)通知（如評價提醒、預(yù)約成功）時，可以用特定的內(nèi)容模版，主動向客戶發(fā)送消息，不支持廣告等營銷類消息。

模版內(nèi)容：可自定義模版消息，不允許紅包、優(yōu)惠、活動通知等營銷類內(nèi)容。標題須以“通知”或“提醒”結(jié)尾，模版消息需要審核，模版添加成功后，即可通過接口調(diào)用模版ID。

只有在用戶觸發(fā)某種行為后，才能主動下發(fā)消息給用戶，期限為7天；不允許在用戶沒做任何操作或未經(jīng)用戶同意接收的前提下，主動下發(fā)消息給用戶；
模板消息可以在模板庫中選擇，可以申請?zhí)砑樱粋€月可以申請三條；
如需跳轉(zhuǎn)到小程序，只能有一個跳轉(zhuǎn)入口，模版中固定有拒收通知選項。

參考官方文檔：https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1433751288

四、接入微信支付

接入微信支付前，需開通微信支付且綁定微信商戶平臺，注意微信系統(tǒng)分為：

微信商戶平臺
微信開放平臺（App支付）
微信公眾平臺：訂閱號、服務(wù)號、小程序

根據(jù)商戶類型不同，To B類的支付手續(xù)費不同，一般為千分之六。

退款是否收取手續(xù)費？——不收取

提現(xiàn)是否收取手續(xù)費？——不收取

注冊商戶平臺時的注意點：

1. 企業(yè)付款到零錢

當用戶發(fā)起提現(xiàn)或退款操作時，從企業(yè)的微信支付商戶賬戶中，支付對應(yīng)金額至用戶的零錢賬戶。不是所有的商戶都有這個功能，開通要求為：選擇結(jié)算周期為“非T+0”商戶類目，否則需要滿足兩個條件：入駐滿 90 天，連續(xù)正常交易 30 天。

2. 自動結(jié)算

當結(jié)算周期到了，微信支付會將商戶號里面的未結(jié)算金額自動劃走，至商戶號綁定的銀行賬戶上面，并且收取約定的費率。問題是——當需要退款給用戶的時候，會發(fā)現(xiàn)賬戶上的錢全部被結(jié)算到銀行卡上，沒有錢退款給用戶，此時就需要關(guān)閉自動結(jié)算。然而，也不是所有商戶都有這個功能，要求：選擇結(jié)算周期為“T+0”商戶類目。

3. 小程序與商戶號綁定

小程序一旦綁定微信支付商戶號，就沒辦法解綁，也就是沒有入口進行更換綁定的商戶號。

綁定方式有：

利用現(xiàn)有小程序作為申請入口，申請一個新的微信支付；
綁定已有的微信支付商戶號。推薦不同的業(yè)務(wù)最好分開結(jié)算，這樣便于財務(wù)進行對賬。如有需要，可以綁定能關(guān)閉自動結(jié)算的微信支付商戶號，能省去許多麻煩。

參考官方文檔：http://kf.qq.com/product/wechatpaymentmerchant.html#hid=hotfaq

五、通用注意點

標準：

小程序頂部導(dǎo)航欄標題：iOS居中，安卓居左；
有關(guān)注公眾號入口（在右上角選擇相關(guān)公眾號可見）；
可以用騰訊地圖定位；
安卓的小程序能放在桌面，iOS不能；
客服不能支持同時回復(fù)文字和圖片，支持圖文消息。

限制點：

小程序不能長按掃碼識別；
iOS 系統(tǒng)下，小程序不支持虛擬支付（VIP會員、充值、錄制課程）；
不能朋友圈；
小程序代碼包不超過2M；
獲取用戶的微信頭像、昵稱、電話等信息，需用戶同意。

六、小結(jié)

根據(jù)2018年微信公開課上公布的數(shù)據(jù)：小程序日活已達到1.7億，已上線58萬個小程序，企業(yè)和個人開發(fā)者超過100萬。

小程序開發(fā)門檻較低，有經(jīng)驗的開發(fā)甚至可以一晚上迅速孵化出熱點小程序。因此，小程序生態(tài)愈加活躍，對于以上小程序迭代中的坑也好、規(guī)則也好，產(chǎn)品經(jīng)理能夠在需求階段了解清除，能夠有效的提升效率，避免延緩迭代進度。

本文由 @Yanssie 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash, 基于CC0協(xié)議

家好，我是皮湯。最近業(yè)務(wù)調(diào)整，組內(nèi)開啟了前端工程化方面的基建，我主要負責 CSS 技術(shù)選型這一塊，針對目前業(yè)界主流的幾套方案進行了比較完善的調(diào)研與比較，分享給大家。

目前整個 CSS 工具鏈、工程化領(lǐng)域的主要方案如下：

而我們技術(shù)選型的標準如下：

- 開發(fā)速度快

- 開發(fā)體驗友好

- 調(diào)試體驗友好

- 可維護性友好

- 擴展性友好

- 可協(xié)作性友好

- 體積小

- 有最佳實踐指導(dǎo)

目前主要需要對比的三套方案：

- Less/Sass + PostCSS 的純 CSS c側(cè)方案

- styled-components / emotion 的純 CSS-in-JS 側(cè)方案

- TailwindCSS 的以寫輔助類為主的 HTML 側(cè)方案

## 純 CSS 側(cè)方案

### 介紹與優(yōu)點

> 維護狀態(tài)：一般

> Star 數(shù)：16.7K

> 支持框架：無框架限制

> 項目地址：https://github.com/less/less.js

Less/Sass + PostCSS 這種方案在目前主流的組件庫和企業(yè)級項目中使用很廣，如 ant-design 等

它們的主要作用如下：

- 為 CSS 添加了類似 JS 的特性，你也可以使用變量、mixin，寫判斷等

- 引入了模塊化的概念，可以在一個 less 文件中導(dǎo)入另外一個 less 文件進行使用

- 兼容標準，可以快速使用 CSS 新特性，兼容瀏覽器 CSS 差異等

這類工具能夠與主流的工程化工具一起使用，如 Webpack，提供對應(yīng)的 loader 如 sass-loader，然后就可以在 React/Vue 項目中建 `.scss` 文件，寫 sass 語法，并導(dǎo)入到 React 組件中生效。

比如我寫一個組件在響應(yīng)式各個斷點下的展示情況的 sass 代碼：

```

.component {

width: 300px;

@media (min-width: 768px) {

width: 600px;

@media (min-resolution: 192dpi) {

background-image: url(/img/retina2x.png);

}

@media (min-width: 1280px) {

width: 800px;

}

```

或?qū)胍恍┯糜跇藴驶癁g覽器差異的代碼：

```

@import "normalize.css";

// component 相關(guān)的其他代碼

```

### 不足

這類方案的一個主要問題就是，只是對 CSS 本身進行了增強，但是在幫助開發(fā)者如何寫更好的 CSS、更高效、可維護的 CSS 方面并沒有提供任何建議。

- 你依然需要自己定義 CSS 類、id，并且思考如何去用這些類、id 進行組合去描述 HTML 的樣式

- 你依然可能會寫很多冗余的 Less/Sass 代碼，然后造成項目的負擔，在可維護性方面也有巨大問題

### 優(yōu)化

- 可以引入 CSS 設(shè)計規(guī)范：BEM 規(guī)范，來輔助用戶在整個網(wǎng)頁的 HTML 骨架以及對應(yīng)的類上進行設(shè)計

- 可以引入 CSS Modules，將 CSS 文件進行 “作用域” 限制，確保在之后維護時，修改一個內(nèi)容不會引起全局中其他樣式的效果

#### BEM 規(guī)范

B （Block）、E（Element）、M（Modifier），具體就是通過塊、元素、行為來定義所有的可視化功能。

拿設(shè)計一個 Button 為例：

```

/* Block */

.btn {}

/* 依賴于 Block 的 Element */

.btn__price {}

/* 修改 Block 風格的 Modifier */

.btn--orange {}

.btn--big {}

```

遵循上述規(guī)范的一個真實的 Button：

```

<span class="btn__text">BIG BUTTON</span>

</a>

```

可以獲得如下的效果：

#### CSS Modules

CSS Modules 主要為 CSS 添加局部作用域和模塊依賴，使得 CSS 也能具有組件化。

一個例子如下：

```

import React from 'react';

import style from './App.css';

export default () => {

return (

Hello World

</h1>

);

};

```

.title {

composes: className;

color: red;

}

```

上述經(jīng)過編譯會變成如下 hash 字符串：

```

Hello World

</h1>

```

._3zyde4l1yATCOkgn-DBWEL {

color: red;

}

```

CSS Modules 可以與普通 CSS、Less、Sass 等結(jié)合使用。

## 純 JS 側(cè)方案

### 介紹與優(yōu)點

> 維護狀態(tài)：一般

> Star 數(shù)：35.2K

> 支持框架：React ，通過社區(qū)支持 Vue 等框架

> 項目地址：https://github.com/styled-components/styled-components

使用 JS 的模板字符串函數(shù)，在 JS 里面寫 CSS 代碼，這帶來了兩個認知的改變：

- 不是在根據(jù) HTML，然后去寫 CSS，而是站在組件設(shè)計的角度，為組件寫 CSS，然后應(yīng)用組件的組合思想搭建大應(yīng)用

- 自動提供類似 CSS Modules 的體驗，不用擔心樣式的全局污染問題

同時帶來了很多 JS 側(cè)才有的各種功能特性，可以讓開發(fā)者用開發(fā) JS 的方式開發(fā) CSS，如編輯器自動補全、Lint、編譯壓縮等。

比如我寫一個按鈕：

```

const Button = styled.button`

/* Adapt the colors based on primary prop */

background: ${props => props.primary ? "palevioletred" : "white"};

color: ${props => props.primary ? "white" : "palevioletred"};

font-size: 1em;

margin: 1em;

padding: 0.25em 1em;

border: 2px solid palevioletred;

border-radius: 3px;

render(

<div>

<Button>Normal</Button>

<Button primary>Primary</Button>

</div>

);

```

可以獲得如下效果：

還可以擴展樣式：

```

// The Button from the last section without the interpolations

const Button = styled.button`

color: palevioletred;

font-size: 1em;

margin: 1em;

padding: 0.25em 1em;

border: 2px solid palevioletred;

border-radius: 3px;

// A new component based on Button, but with some override styles

const TomatoButton = styled(Button)`

color: tomato;

border-color: tomato;

render(

<div>

<Button>Normal Button</Button>

<TomatoButton>Tomato Button</TomatoButton>

</div>

);

```

可以獲得如下效果：

### 不足

雖然這類方案提供了在 JS 中寫 CSS，充分利用 JS 的插值、組合等特性，然后應(yīng)用 React 組件等組合思想，將組件與 CSS 進行細粒度綁定，讓 CSS 跟隨著組件一同進行組件化開發(fā)，同時提供和組件類似的模塊化特性，相比 Less/Sass 這一套，可以復(fù)用 JS 社區(qū)的最佳實踐等。

但是它仍然有一些不足：

- 仍然是是對 CSS 增強，提供非常大的靈活性，開發(fā)者仍然需要考慮如何去組織自己的 CSS

- 沒有給出一套 “有觀點” 的最佳實踐做法

- 在上層也缺乏基于 styled-components 進行復(fù)用的物料庫可進行參考設(shè)計和使用，導(dǎo)致在初始化使用時開發(fā)速度較低

- 在 JS 中寫 CSS，勢必帶來一些本屬于 JS 的限制，如 TS 下，需要對 Styled 的組件進行類型注釋

- 官方維護的內(nèi)容只兼容 React 框架，Vue 和其他框架都由社區(qū)提供支持

整體來說不太符合團隊協(xié)作使用，需要人為總結(jié)最佳實踐和規(guī)范等。

### 優(yōu)化

- 尋求一套寫 CSS 的最佳實踐和團隊協(xié)作規(guī)范

- 能夠擁有大量的物料庫或輔助類等，提高開發(fā)效率，快速完成應(yīng)用開發(fā)

## 偏向 HTML 側(cè)方案

### 介紹與優(yōu)點

> 維護狀態(tài)：積極

> Star 數(shù)：48.9K

> 支持框架：React、Vue、Svelte 等主流框架

> 項目地址：https://github.com/tailwindlabs/tailwindcss

典型的是 TailwindCSS，一個輔助類優(yōu)先的 CSS 框架，提供如 `flex` 、`pt-4` 、`text-center` 、`rotate-90` 這樣實用的類名，然后基于這些底層的輔助類向上組合構(gòu)建任何網(wǎng)站，而且只需要專注于為 HTML 設(shè)置類名即可。

一個比較形象的例子可以參考如下代碼：

```

<button class="btn btn--secondary">Decline</button>

<button class="btn btn--primary">Accept</button>

```

上述代碼應(yīng)用 BEM 風格的類名設(shè)計，然后設(shè)計兩個按鈕，而這兩個類名類似主流組件庫里面的 Button 的不同狀態(tài)的設(shè)計，而這兩個類又是由更加基礎(chǔ)的 TailwindCSS 輔助類組成：

```

.btn {

@apply text-base font-medium rounded-lg p-3;

}

.btn--primary {

@apply bg-rose-500 text-white;

}

.btn--secondary {

@apply bg-gray-100 text-black;

}

```

上面的輔助類包含以下幾類：

- 設(shè)置文本相關(guān)： `text-base` 、`font-medium` 、`text-white` 、`text-black`

- 設(shè)置背景相關(guān)的：`bg-rose-500` 、`bg-gray-100`

- 設(shè)置間距相關(guān)的：`p-3`

- 設(shè)置邊角相關(guān)的：`rounded-lg`

通過 Tailwind 提供的 `@apply` 方法來對這些輔助類進行組合構(gòu)建更上層的樣式類。

上述的最終效果展示如下：

可以看到 TailwindCSS 將我們開發(fā)網(wǎng)站的過程抽象成為使用 Figma 等設(shè)計軟件設(shè)計界面的過程，同時提供了一套用于設(shè)計的規(guī)范，相當于內(nèi)置最佳實踐，如顏色、陰影、字體相關(guān)的內(nèi)容，一個很形象的圖片可以說明這一點：

TailwindCSS 為我們規(guī)劃了一個元素可以設(shè)置的屬性，并且為每個屬性給定了一組可以設(shè)置的值，這些屬性+屬性值組合成一個有機的設(shè)計系統(tǒng)，非常便于團隊協(xié)作與共識，讓我們開發(fā)網(wǎng)站就像做設(shè)計一樣簡單、快速，但是整體風格又能保持一致。

TailwindCSS 同時也能與主流組件庫如 React、Vue、Svelte 結(jié)合，融入基于組件的 CSS 設(shè)計思想，但又只需要修改 HTML 上的類名，如我們設(shè)計一個食譜組件：

```

// Recipes.js

import Nav from './Nav.js'

import NavItem from './NavItem.js'

import List from './List.js'

import ListItem from './ListItem.js'

export default function Recipes({ recipes }) {

return (

<Nav>

<NavItem href="/featured" isActive>Featured</NavItem>

<NavItem href="/popular">Popular</NavItem>

<NavItem href="/recent">Recent</NavItem>

</Nav>

<List>

{recipes.map((recipe) => (

))}

</List>

</div>

)

}

// Nav.js

export default function Nav({ children }) {

return (

{children}

</ul>

</nav>

)

}

// NavItem.js

export default function NavItem({ href, isActive, children }) {

return (

<li>

href={href}

className={`block px-4 py-2 rounded-md ${isActive ? 'bg-amber-100 text-amber-700' : ''}`}

{children}

</a>

</li>

)

}

// List.js

export default function List({ children }) {

return (

{children}

</ul>

)

}

//ListItem.js

export default function ListItem({ recipe }) {

return (

{recipe.title}

</h2>

<div>

<dd>

<abbr title={`${recipe.time} minutes`}>{recipe.time}m</abbr>

</dd>

</div>

<div>

<dt className="sr-only">Difficulty</dt>

<dd> · {recipe.difficulty}</dd>

</div>

<div>

<dt className="sr-only">Servings</dt>

<dd> · {recipe.servings} servings</dd>

</div>

<dt className="inline">By</dt>{' '}

<dd className="inline text-black">{recipe.author}</dd>

</div>

<span className="sr-only">Rating</span>

</svg>

</dt>

<dd>{recipe.rating}</dd>

</div>

</dl>

</div>

</article>

)

}

```

上述食譜的效果如下：

可以看到我們無需寫一行 CSS，而是在 HTML 里面應(yīng)用各種輔助類，結(jié)合 React 的組件化設(shè)計，既可以輕松完成一個非常現(xiàn)代化且好看的食譜組件。

除了上面的特性，TailwindCSS 在響應(yīng)式、新特性支持、Dark Mode、自定義配置、自定義新的輔助類、IDE 方面也提供非常優(yōu)秀的支持，除此之外還有基于 TailwindCSS 構(gòu)建的物料庫 Tailwind UI ，提供各種各樣成熟、好看、可用于生產(chǎn)的物料庫：

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1cb983da6f71470b91ac764d14907998~tplv-k3u1fbpfcp-zoom-1.image)

因為需要自定的 CSS 不多，而需要自定義的 CSS 可以定義為可復(fù)用的輔助類，所以在可維護性方面也是極好的。

### 不足

- 因為要引入一個額外的運行時，TailwindCSS 輔助類到 CSS 的編譯過程，而隨著組件越來越多，需要編譯的工作量也會變大，所以速度會有影響

- 過于底層，相當于給了用于設(shè)計的最基礎(chǔ)的指標，但是如果我們想要快速設(shè)計網(wǎng)站，那么可能還需要一致的、更加上層的組件庫

- 相當于引入了一套框架，具有一定的學(xué)習成本和使用成本

### 優(yōu)化

- Tailwind 2.0 支持 [JIT](https://blog.tailwindcss.com/tailwindcss-2-1 "JIT")，可以大大提升編譯速度，可以考慮引入

- 基于 TailwindCSS，設(shè)計一套符合自身風格的上層組件庫、物料庫，便于更加快速開發(fā)

- 提前探索、學(xué)習和總結(jié)一套教程與開發(fā)最佳實踐

- 探索 styled-components 等結(jié)合 TailwindCSS 的開發(fā)方式

## 參考鏈接

- [CSS 工程化發(fā)展歷程](https://bytedance.feishu.cn/docs/doccnTRF0OZtJMgKuo3y0hIDMbc# "CSS 工程化發(fā)展歷程")

/ 感謝支持/

以上便是本次分享的全部內(nèi)容，希望對你有所幫助^_^

喜歡的話別忘了分享、點贊、收藏三連哦~

歡迎關(guān)注公眾號 程序員巴士，來自字節(jié)、蝦皮、招銀的三端兄弟，分享編程經(jīng)驗、技術(shù)干貨與職業(yè)規(guī)劃，助你少走彎路進大廠。

o語言中的鎖簡單易用，本文整理一下鎖的實現(xiàn)原理。

Golang中鎖有兩種，互斥鎖Mutex和讀寫互斥鎖RWMutex，互斥鎖也叫讀鎖，讀寫鎖也叫讀鎖，相互之間的關(guān)系為：

寫鎖需要阻塞寫鎖：一個協(xié)程擁有寫鎖時，其他協(xié)程寫鎖定需要阻塞
寫鎖需要阻塞讀鎖：一個協(xié)程擁有寫鎖時，其他協(xié)程讀鎖定需要阻塞
讀鎖需要阻塞寫鎖：一個協(xié)程擁有讀鎖時，其他協(xié)程寫鎖定需要阻塞
讀鎖不能阻塞讀鎖：一個協(xié)程擁有讀鎖時，其他協(xié)程也可以擁有讀鎖

1.使用

互斥鎖和讀寫鎖在使用上沒有很大區(qū)別

互斥鎖使用Lock()進行加鎖，使用Unlock()進行解鎖
讀寫鎖使用RLock()加讀鎖，使用RUnlock()進行解讀鎖；使用Lock()加寫鎖，使用Unlock解寫鎖，和互斥鎖功能一致；

但兩者使用場景不同：

互斥鎖會將操作串行化，可以保證操作完全有序，適合資源只能由一個協(xié)程進行操作的情況，并發(fā)能力弱；
讀寫鎖適合讀多寫少的情況，并發(fā)能有比較強。

package main
import (
   "fmt"
   "sync"
   "time"
)
/**
 * @Author: Jason Pang
 * @Description: 測試互斥鎖
 */
func testMutex() {
   count := 0
   var l sync.Mutex
   for i := 0; i < 10; i++ {
      go func() {
         l.Lock()
         defer l.Unlock()
         fmt.Println("---------互斥鎖", count)
         count++
      }()
   }
}
/**
 * @Author: Jason Pang
 * @Description: 測試讀寫鎖
 */
func testRWMutex() {
   count := 0
   var l sync.RWMutex
   for i := 0; i < 10; i++ {
      go func() {
         l.RLock()
         defer l.RUnlock()
         fmt.Println("---------讀寫互斥鎖", count)
         count++
      }()
   }
}
func main() {
   testMutex()
   testRWMutex()
   time.Sleep(10 * time.Second)
}

輸出：

可以看出使用互斥鎖后，count值是順序增加的，而使用讀寫互斥鎖，數(shù)據(jù)則是無序的。

2.基礎(chǔ)知識

講鎖的具體實現(xiàn)原理之前，需要先復(fù)習幾個基礎(chǔ)知識：進程同步、信號量和自旋。

2.1進程同步

進程同步本質(zhì)上是靠控制對臨界區(qū)的訪問權(quán)限實現(xiàn)的。

臨界資源：把在一段時間內(nèi)只允許一個進程訪問的資源稱為臨界資源或獨占資源。計算機系統(tǒng)中的大多數(shù)物理設(shè)備，以及某些軟件中所用的棧、變量和表格，都屬于臨界資源，它們要求被互斥地共享
臨界區(qū)：在每個進程中訪問臨界資源的那段代碼稱為臨界區(qū)(critical section)。若能保證諸進程互斥地進入自己的臨界區(qū)，便可實現(xiàn)諸進程對臨界資源的互斥訪問。

進入?yún)^(qū)(entry section)：如果此刻該臨界資源未被訪問，進程便可進入臨界區(qū)對該資源進行訪問，并設(shè)置它正被訪問的標志；如果此刻該臨界資源正被某進程訪問，則本進程不能進入臨界區(qū)。
退出區(qū)(exit section)：用于將臨界區(qū)正被訪問的標志恢復(fù)為未被訪問的標志。

同步機制規(guī)則

(1) 空閑讓進。當無進程處于臨界區(qū)時，表明臨界資源處于空閑狀態(tài)，應(yīng)允許一個請求進入臨界區(qū)的進程立即進入自己的臨界區(qū)，以有效地利用臨界資源。

(2) 忙則等待。當已有進程進入臨界區(qū)時，表明臨界資源正在被訪問，因而其它試圖進入臨界區(qū)的進程必須等待，以保證對臨界資源的互斥訪問。

(3) 有限等待。對要求訪問臨界資源的進程，應(yīng)保證在有限時間內(nèi)能進入自己的臨界區(qū)，以免陷入“死等”狀態(tài)。

(4) 讓權(quán)等待。當進程不能進入自己的臨界區(qū)時，應(yīng)立即釋放處理機，以免進程陷入“忙等”狀態(tài)。

這個規(guī)則和現(xiàn)實一致：如果有空閑我就可以用吧（空閑讓進）；如果不空閑，為了有序我可以等待（忙則等待）；我等待的時候沒別的事情可以做，那可以去一邊休息吧（讓權(quán)等待）；你們不能讓我老等著吧（有限等待）；

2.2信號量

1965 年，荷蘭學(xué)者 Dijkstra 提出的信號量(Semaphores)機制是一種卓有成效的進程同步工具。Dijkstra，YYDS。

2.2.1類型

信號量現(xiàn)在已發(fā)展為如下四種類型：

整型信號量
記錄型信號量
AND型信號量
信號量集

雖然信號量有不同類型，但核心是對：一個用于表示資源數(shù)目的整型量 S，僅能通過兩個標準的原子操作(Atomic Operation) wait(S)和 signal(S)來訪問。wait用于將S值變小，signal用于將S值增加，偽代碼如下：

wait(S)：while S<=0 do no-op；
	 S:=S-1；
signal(S)：S:=S+1；

2.2.2應(yīng)用

利用信號量實現(xiàn)進程互斥為使多個進程能互斥地訪問某臨界資源，只須為該資源設(shè)置一互斥信號量 mutex，并設(shè)其初始值為 1，然后將各進程訪問該資源的臨界區(qū)(critical section)置于 wait(mutex)和 signal(mutex)操作之間即可。
利用信號量實現(xiàn)前驅(qū)關(guān)系設(shè)有兩個并發(fā)執(zhí)行的進程 P1 和 P2。P1 中有語句 S1；P2 中有語句 S2。我們希望在 S1 執(zhí)行后再執(zhí)行 S2。為實現(xiàn)這種前趨關(guān)系，我們只須使進程 P1 和 P2 共享一個公用信號量 S，并賦予其初值為 0，將 signal(S)操作放在語句 S1 后面；而在 S2 語句前面插入 wait(S)操作，即在進程 P1 中，用 S1；signal(S)；在進程 P2 中，用 wait(S)；S2；

2.3自旋

同步機制規(guī)則里有讓權(quán)等待，自旋其實就是說在進程不能進入自己的臨界區(qū)時是如何處理的。

2.3.1定義

加鎖時，如果發(fā)現(xiàn)該鎖當前由其他協(xié)程持有，嘗試加鎖的協(xié)程并不是馬上轉(zhuǎn)入阻塞，而是會持續(xù)的探測鎖是否被釋放，這個過程即為自旋過程。自旋時間很短，但如果在自旋過程中發(fā)現(xiàn)鎖已被釋放，那么協(xié)程可以立即獲取鎖。

2.3.2過程

自旋過程為先檢查是否可以加鎖，如果不可以，執(zhí)行CPU PAUSE指令，CPU對該指令什么都不做，一般為30個時鐘周期。PAUSE執(zhí)行后，再檢查是否可以加鎖，循環(huán)往復(fù)。

在這個過程中，進程仍然是執(zhí)行狀態(tài)，不是睡眠狀態(tài)。

2.3.3優(yōu)勢

自旋主要為了更加高效，減少損耗。自旋的優(yōu)勢是更充分的利用CPU，盡量避免協(xié)程切換。因為當前申請加鎖的協(xié)程擁有CPU，如果經(jīng)過短時間的自旋可以獲得鎖，當前協(xié)程可以繼續(xù)運行，不必進入阻塞狀態(tài)。

2.3.4條件

自旋不能隨便使用，否則不但發(fā)揮不了優(yōu)勢，還會帶來更多損耗，舉個簡單的例子：如果自旋次數(shù)不限制，而獲得鎖的進程很長時間后才釋放鎖，則自旋的進程這段時間CPU完全浪費了。

所以使用自旋，一定要滿足一下條件：

自旋次數(shù)要足夠小，通常為4，即自旋最多4次
CPU核數(shù)要大于1，否則自旋沒有意義，因為此時不可能有其他協(xié)程釋放鎖
調(diào)度機制中的Process數(shù)量要大于1，否則自旋沒有意義
調(diào)度機制中的可運行隊列必須為空，否則會延遲協(xié)程調(diào)度，需要把CPU讓給更需要的進程

2.3.5問題

自旋有個特性，無視正在排隊等待加鎖的進程，在自旋過程中，獲取到鎖便可加鎖，類似于插隊。

所以使用自旋會引發(fā)問題：極端情況下，很多進程正排隊等待加鎖，此時有進程剛到，開始自旋加鎖，如果成功，該進程便插隊成功加鎖。如果此時不斷有進程自旋加鎖，則在排隊的進程將長時間無法獲取到鎖。

一般解決方案為：鎖添加饑餓狀態(tài)，該狀態(tài)下不允許自旋。

3.實現(xiàn)原理

3.1互斥鎖Mutex

3.1.1 結(jié)構(gòu)體

Mutex結(jié)構(gòu)體如下：

// A Mutex must not be copied after first use.
// Mutex被使用后，不可以將其復(fù)制。(意思是不能復(fù)制值，可以做成引用復(fù)制)
// 復(fù)制容易導(dǎo)致非預(yù)期的死鎖，https://mozillazg.com/2019/04/notes-about-go-lock-mutex.html#hidcopy
type Mutex struct {
   state int32
   sema  uint32
}

state表示互斥鎖的狀態(tài)，比如是否被鎖定等。
sema表示信號量，協(xié)程阻塞等待該信號量，解鎖的協(xié)程釋放信號量從而喚醒等待信號量的協(xié)程。

state是32位的整型變量，內(nèi)部實現(xiàn)時把該變量分成四份，用于記錄Mutex的四種狀態(tài)。

const (
   mutexLocked = 1 << iota //值1
   mutexWoken //值2 
   mutexStarving //值4
)

Locked: 表示該Mutex是否已被鎖定，0：沒有鎖定 1：已被鎖定。

Woken: 表示是否有協(xié)程已被喚醒，0：沒有協(xié)程喚醒 1：已有協(xié)程喚醒，正在加鎖過程中。釋放鎖時，如果正常模式下，不會再喚醒其它協(xié)程。

Starving：表示該Mutex是否處理饑餓狀態(tài)， 0：沒有饑餓 1：饑餓狀態(tài)，說明有協(xié)程阻塞了超過1ms。

Waiter: 表示阻塞等待鎖的協(xié)程個數(shù)，協(xié)程解鎖時根據(jù)此值來判斷是否需要釋放信號量

協(xié)程之間搶鎖實際上是搶給Locked賦值的權(quán)利，能給Locked域置1，就說明搶鎖成功。搶不到的話就阻塞等待

Mutex.sema信號量，一旦持有鎖的協(xié)程解鎖，等待的協(xié)程會依次被喚醒。

3.1.2 互斥公平

go1.13中，講述starving、woken、locked是如何使用的，對原文進行翻譯

// Mutex fairness.
//
// Mutex can be in 2 modes of operations: normal and starvation.
// In normal mode waiters are queued in FIFO order, but a woken up waiter
// does not own the mutex and competes with new arriving goroutines over
// the ownership. New arriving goroutines have an advantage -- they are
// already running on CPU and there can be lots of them, so a woken up
// waiter has good chances of losing. In such case it is queued at front
// of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,
// it switches mutex to the starvation mode.
//
// In starvation mode ownership of the mutex is directly handed off from
// the unlocking goroutine to the waiter at the front of the queue.
// New arriving goroutines don't try to acquire the mutex even if it appears
// to be unlocked, and don't try to spin. Instead they queue themselves at
// the tail of the wait queue.
//
// If a waiter receives ownership of the mutex and sees that either
// (1) it is the last waiter in the queue, or (2) it waited for less than 1 ms,
// it switches mutex back to normal operation mode.
//
// Normal mode has considerably better performance as a goroutine can acquire
// a mutex several times in a row even if there are blocked waiters.
// Starvation mode is important to prevent pathological cases of tail latency.

互斥量有兩種模式：正常模式和饑餓模式。

正常模式：正常模式下等待的協(xié)程按照先入先出排列，當一個協(xié)程被喚醒后并不是直接擁有鎖，該協(xié)程需要和剛剛到達的協(xié)程一起競爭鎖的所有權(quán)。新到的協(xié)程有個優(yōu)勢，那就是它已經(jīng)在CPU上運行了，而且新到的協(xié)程可能有很多，所以被喚醒的協(xié)程極有可能搶占不到鎖。在這種情況下，被喚醒的協(xié)程會被放置于等待隊列的隊頭。如果等待的協(xié)程超過1ms內(nèi)沒有獲取到鎖，將會把鎖置為饑餓模式。

饑餓模式：在饑餓模式下，解鎖的協(xié)程會將鎖的所有權(quán)直接交給等待隊列中位于隊頭的協(xié)程。正好解鎖的那一刻有新的協(xié)程到達，新到達的協(xié)程也不會嘗試自旋獲取鎖。相反，他們會將自己置于等待隊列的隊尾。

如果等待隊列中的協(xié)程獲取到鎖，它會查看

(1)自己是否是等待隊列中最后一個協(xié)程

(2)自己等待的時間是否小于1ms

如果有任意一個條件滿足，將會將鎖改為普通模式。

一般認為普通模式會有更好的性能，因為即使有等待的協(xié)程，新的協(xié)程可以連續(xù)獲取到鎖。饑餓模式能夠防止等待協(xié)程長時間獲取不到鎖。

3.1.3 Lock

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
// 如果鎖已經(jīng)被占用了，則將調(diào)用Lock的協(xié)程阻塞，知道鎖被釋放
func (m *Mutex) Lock() {
   // Fast path: grab unlocked mutex.
   // 如果鎖即沒被占用、也不是饑餓狀態(tài)、也沒有喚醒協(xié)程、也沒有等待的協(xié)程，直接加鎖成功
   // 這是比較完美的一種狀態(tài)
   if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
      if race.Enabled { //默認是false，所以可以不用管
         race.Acquire(unsafe.Pointer(m))
      }
      return
   }
   // Slow path (outlined so that the fast path can be inlined)
   m.lockSlow()
}
func (m *Mutex) lockSlow() {
   var waitStartTime int64
   starving := false
   awoke := false
   iter := 0
   old := m.state
   for {
      // Don't spin in starvation mode, ownership is handed off to waiters
      // so we won't be able to acquire the mutex anyway.
      // 如果是正常模式且鎖被搶占了，自己符合自旋條件，就自旋
     	// 因為按照規(guī)定，饑餓模式下需要保證等待隊列中的協(xié)程能夠獲得鎖的所有權(quán)，防止等待隊列餓死
      // 如果鎖變?yōu)轲囸I狀態(tài)或者已經(jīng)解鎖了，或者不符合自旋條件了就結(jié)束自旋
      if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
         // Active spinning makes sense.
         // Try to set mutexWoken flag to inform Unlock
         // to not wake other blocked goroutines.
         // 如果等待隊列有協(xié)程、鎖沒有設(shè)置喚醒狀態(tài)，就努力設(shè)置喚醒狀態(tài)
         // 這么做的好處是，當鎖解鎖的時候，不會去喚醒已經(jīng)阻塞的協(xié)程，保證自己更大概率獲取到鎖
         if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
            atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
            awoke = true
         }
         runtime_doSpin()
         iter++
         old = m.state
         continue
      }
      // 此處說明鎖變?yōu)轲囸I狀態(tài)或者已經(jīng)解鎖了，或者不符合自旋條件了（仍為鎖定狀態(tài)）
      // 鎖狀態(tài)包含-饑餓鎖定、饑餓未鎖定、正常鎖定、正常未鎖定
      // 獲取鎖最新的狀態(tài)
      new := old
      // Don't try to acquire starving mutex, new arriving goroutines must queue.
      // 如果是正常狀態(tài)，嘗試加鎖。饑餓狀態(tài)下要出讓競爭權(quán)利，肯定不能加鎖的
      if old&mutexStarving == 0 {
         new |= mutexLocked
      }
      // 如果鎖還是被占用的或者鎖是饑餓狀態(tài)，只能將自己放到等待隊列上
      // 到了這個階段，遇到這些狀態(tài)，協(xié)程只能躺平。饑餓狀態(tài)要出讓競爭權(quán)利
      if old&(mutexLocked|mutexStarving) != 0 {
         new += 1 << mutexWaiterShift
      }
      // The current goroutine switches mutex to starvation mode.
      // But if the mutex is currently unlocked, don't do the switch.
      // Unlock expects that starving mutex has waiters, which will not
      // be true in this case.
      // 如果自身已經(jīng)到饑餓狀態(tài)了，而且鎖是被占用情況下，將鎖改為饑餓狀態(tài)
      // 鎖未被占用不能改為饑餓模式，是因為如果鎖沒有被占用，但是鎖是饑餓狀態(tài)，那應(yīng)該有等待隊列。
      // 如果鎖未被占用卻改為饑餓狀態(tài)，違背了這個條件。(不是很明白這句話)
        if starving && old&mutexLocked != 0 {
         new |= mutexStarving
      }
      // 如果該協(xié)程設(shè)置鎖的喚醒狀態(tài)，需要將喚醒狀態(tài)進行重置。
      // 因為改協(xié)程要么獲得了鎖、要么進入休眠，都和喚醒狀態(tài)無關(guān)了
      if awoke {
         // The goroutine has been woken from sleep,
         // so we need to reset the flag in either case.
         if new&mutexWoken == 0 {
            throw("sync: inconsistent mutex state")
         }
         new &^= mutexWoken
      }
      // old  -> new
      // (0,1)正常且已鎖定 -> (+1,1?,1) 等待加一，狀態(tài)待定，加鎖   ->  加到等待隊列
      // (0,0)正常且未鎖定 -> (+0,0 ,1) 等待不變，正常狀態(tài)，加鎖   ->  加鎖成功
      // (1,1)饑餓且已鎖定 -> (+1,1?,1) 等待加一，饑餓待定，加鎖   ->  加到等待隊列
      // (1,0)饑餓且未鎖定 -> (+1,1 ,0) 等待加一，饑餓狀態(tài)，不加鎖  ->  加到等待隊列
      if atomic.CompareAndSwapInt32(&m.state, old, new) {//如果CAS成功
         //如果鎖為未鎖定且正常狀態(tài)，表明占有鎖成功，加鎖操作完畢
         if old&(mutexLocked|mutexStarving) == 0 {
            break // locked the mutex with CAS
         }
         // If we were already waiting before, queue at the front of the queue.
         queueLifo := waitStartTime != 0
         if waitStartTime == 0 {
            waitStartTime = runtime_nanotime()
         }
        
         // 走到此處，說明協(xié)程沒有獲取到鎖，調(diào)用runtime_SemacquireMutex，將該協(xié)程掛起
         // waitStartTime能夠判斷該協(xié)程是新來的還是被喚醒的
         // 如果是新來的，則加入隊列尾部，等待喚醒，queueLifo=false
         // 如果是從等待隊列中喚醒的，則加入隊列頭部，queueLifo=true
         // 如果后面該協(xié)程被喚醒，就從該位置繼續(xù)往下執(zhí)行
         runtime_SemacquireMutex(&m.sema, queueLifo, 1)
         // 此刻說明該協(xié)程被喚醒了
         // 判斷該協(xié)程是否長時間沒有獲取到鎖，如果是的話，就是饑餓的協(xié)程
         starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
         // 協(xié)程被掛起的時間有點長，需要重新獲取一下當前鎖的狀態(tài)
         old = m.state
         // 表示當前是饑餓狀態(tài)的情況。按照設(shè)定，饑餓狀態(tài)下，被喚醒的協(xié)程直接獲得鎖。
         if old&mutexStarving != 0 {
            // If this goroutine was woken and mutex is in starvation mode,
            // ownership was handed off to us but mutex is in somewhat
            // inconsistent state: mutexLocked is not set and we are still
            // accounted as waiter. Fix that.
            // 饑餓狀態(tài)下，我被喚醒，結(jié)果發(fā)現(xiàn)鎖沒釋放、喚醒值是1、等待列表沒有協(xié)程了（不把我算作協(xié)程了）
            // 不符合設(shè)定，果斷有問題啊
            if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
               throw("sync: inconsistent mutex state")
            }
            // 值是7，因為此時鎖狀態(tài)為未鎖定，使用7可以達到等待數(shù)量減一，同時將鎖設(shè)置為鎖定的效果
            delta := int32(mutexLocked - 1<<mutexWaiterShift)
            // 如果喚醒等待隊列的協(xié)程不饑餓、或者這個協(xié)程是等待隊列中最后一個協(xié)程，就改為正常狀態(tài)
            if !starving || old>>mutexWaiterShift == 1 {
               // Exit starvation mode.
               // Critical to do it here and consider wait time.
               // Starvation mode is so inefficient, that two goroutines
               // can go lock-step infinitely once they switch mutex
               // to starvation mode.
               delta -= mutexStarving
            }
            // 將鎖狀態(tài)設(shè)置為等待數(shù)量減一，同時設(shè)置為鎖定。加鎖成功
            // 這個計算方法太秀了
            atomic.AddInt32(&m.state, delta)
            break
         }
         // 本協(xié)程千真萬確就是被系統(tǒng)喚醒的協(xié)程
         awoke = true
         // 自旋次數(shù)重置為0
         iter = 0
      } else { //如果CAS失敗，則重新開始
         old = m.state
      }
   }
   if race.Enabled {
      race.Acquire(unsafe.Pointer(m))
   }
}

3.1.3 UnLock

// Unlock unlocks m.
// It is a run-time error if m is not locked on entry to Unlock.
// 如果在解鎖的時候，鎖是沒有被鎖定的，則報運行時錯誤。
//
// A locked Mutex is not associated with a particular goroutine.
// It is allowed for one goroutine to lock a Mutex and then
// arrange for another goroutine to unlock it.
// 加鎖和解鎖可以不是同一個協(xié)程
func (m *Mutex) Unlock() {
   if race.Enabled { //默認是false
      _ = m.state
      race.Release(unsafe.Pointer(m))
   }
   // Fast path: drop lock bit.
   // 不是饑餓狀態(tài)，沒有等待的協(xié)程、沒有喚醒，直接解鎖完畢
   new := atomic.AddInt32(&m.state, -mutexLocked)
   // 說明可能為饑餓狀態(tài)、有等待協(xié)程、有喚醒的協(xié)程，事情沒處理完，還得繼續(xù)處理
   if new != 0 {
      // Outlined slow path to allow inlining the fast path.
      // To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock.
      m.unlockSlow(new)
   }
}
func (m *Mutex) unlockSlow(new int32) {
   if (new+mutexLocked)&mutexLocked == 0 {
      throw("sync: unlock of unlocked mutex")
   }
   //如果是正常模式
   if new&mutexStarving == 0 {
      old := new
      for {
         // If there are no waiters or a goroutine has already
         // been woken or grabbed the lock, no need to wake anyone.
         // In starvation mode ownership is directly handed off from unlocking
         // goroutine to the next waiter. We are not part of this chain,
         // since we did not observe mutexStarving when we unlocked the mutex above.
         // So get off the way.
         // 如果等待列表里沒有協(xié)程了，或者已經(jīng)有喚醒的協(xié)程了，就無需浪費精力喚醒其它協(xié)程了
         if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
            return
         }
         // Grab the right to wake someone.
         // 等待協(xié)程數(shù)量減1，并將鎖的喚醒位置為1
         new = (old - 1<<mutexWaiterShift) | mutexWoken
         if atomic.CompareAndSwapInt32(&m.state, old, new) {
            runtime_Semrelease(&m.sema, false, 1)
            return
         }
         old = m.state
      }
   } else {//如果是饑餓模式
      // Starving mode: handoff mutex ownership to the next waiter.
      // Note: mutexLocked is not set, the waiter will set it after wakeup.
      // But mutex is still considered locked if mutexStarving is set,
      // so new coming goroutines won't acquire it.
      // 饑餓模式下，直接將鎖的所有權(quán)交給等待隊列中的第一個
      // 注意：鎖的locked位沒有被設(shè)置，喚醒的協(xié)程后面會進行設(shè)置
      // 盡管沒有設(shè)置locked位，但是在饑餓模式下，新來的協(xié)程也是無法獲取到鎖的。
      runtime_Semrelease(&m.sema, true, 1)
   }
}

3.1.4 函數(shù)說明

【runtime_canSpin】：在 src/runtime/proc.go 中被實現(xiàn) sync_runtime_canSpin；表示是否可以保守的自旋，golang中自旋鎖并不會一直自旋下去，在runtime包中runtime_canSpin方法做了一些限制, 傳遞過來的iter大等于4或者cpu核數(shù)小等于1，最大邏輯處理器大于1，至少有個本地的P隊列，并且本地的P隊列可運行G隊列為空。

【runtime_doSpin】：在 src/runtime/proc.go 中被實現(xiàn) sync_runtime_doSpin；表示會調(diào)用procyield函數(shù)，該函數(shù)也是匯編語言實現(xiàn)。函數(shù)內(nèi)部循環(huán)調(diào)用PAUSE指令。PAUSE指令什么都不做，但是會消耗CPU時間，在執(zhí)行PAUSE指令時，CPU不會對它做不必要的優(yōu)化。

【runtime_SemacquireMutex】：在 src/runtime/sema.go 中被實現(xiàn) sync_runtime_SemacquireMutex；表示通過信號量阻塞當前協(xié)程。

【runtime_Semrelease】: 在src/runtime/sema.go 中被實現(xiàn) sync_runtime_Semrelease。表示通過信號量解除當前協(xié)程阻塞。

3.1.5 流程圖

https://www.processon.com/view/link/60f4e1021e085376da5c05f8

Go互斥鎖實現(xiàn)邏輯很復(fù)雜，能夠看到大量的性能優(yōu)化方面的代碼，所以導(dǎo)致整個邏輯很難理解。大家即使看了注釋和流程圖，理解起來應(yīng)該還是會有些困難。我的建議是，一是搞懂lock、woken、starving所代表的功能，二是不是要1.13版本的鎖實現(xiàn)，可以看早期實現(xiàn)，會更加簡單一些。

4.總結(jié)

本來以為寫鎖的實現(xiàn)會很快能完成，結(jié)果看這一兩百行代碼用了差不多一個星期。個人也不太建議看1.13鎖的具體實現(xiàn)，太過于繁雜了。可以看一下https://www.cnblogs.com/niniwzw/p/3153955.html，講了鎖的演變。

更容易讓大家理解的方式是使用狀態(tài)機，將加鎖和寫鎖操作都放入狀態(tài)機中，但鎖狀態(tài)分四部分，加上各種操作，繪制起來比較耗時，如果大家有興趣可以繪制一下。

寫這篇文章的時候，有些資料查的大學(xué)教程《計算機操作系統(tǒng)》，發(fā)覺這些書真是好書，不但準確而且易懂，以前都是死記硬背，現(xiàn)在感覺簡直是寶書。

讀寫鎖另起一篇文章寫吧，這篇已經(jīng)太長了，寫不動了。

資料

線程同步（互斥鎖與信號量的作用與區(qū)別）
信號量及其使用和實現(xiàn)(超詳細)
Go專家編程
Golang同步機制的實現(xiàn)
【我的架構(gòu)師之路】- 說一說go中的sync包
Golang 互斥鎖內(nèi)部實現(xiàn)
go sync.Mutex 設(shè)計思想與演化過程（一）
一文讀懂go中semaphore(信號量)源碼
Go: 關(guān)于鎖（mutex）的一些使用注意事項

在線咨詢

上一篇：HTML5大文件上傳技術(shù)
下一篇：Web前端最強JavaScript Excel處理插件-exceljs

您的項目需求

*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商

5個要點，避免踩坑小程序

一、小程序一鍵更新

二、小程序跳轉(zhuǎn)類型

1. H5

2. 公眾號文章

3. 小程序

三、推送微信服務(wù)通知

四、接入微信支付

1. 企業(yè)付款到零錢

2. 自動結(jié)算

3. 小程序與商戶號綁定

五、通用注意點

六、小結(jié)

/ 感謝支持/

1.使用

2.基礎(chǔ)知識

2.1進程同步

2.2信號量

2.2.1類型

2.2.2應(yīng)用

2.3自旋

2.3.1定義

2.3.2過程

2.3.3優(yōu)勢

2.3.4條件

2.3.5問題

3.實現(xiàn)原理

3.1互斥鎖Mutex

3.1.1 結(jié)構(gòu)體

3.1.2 互斥公平

3.1.3 Lock

3.1.3 UnLock

3.1.4 函數(shù)說明

3.1.5 流程圖

4.總結(jié)

資料

您的項目需求