整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
程序作為產品形態的一種，比App輕量、比Web網頁簡潔，但由于依賴微信生態，必須遵守微信生態的規則。作為產品經理，參與小程序產品迭代已有四個月，踩過不少坑；經歷幾次迭代，對小程序規則有了一定了解。希望在這里能夠總結小程序這種產品形態，有哪些注意點。
毫無約束的自由往往無法創新，在一定規則內的自由才是真正的自由。而微信生態就是小程序必須遵守的規則，遵守微信的克制，五花八門的小程序一個個冒出頭來，小程序成為追逐線上紅利的絕佳土壤。
小程序的上線流程：
小程序的重啟機制：小程序沒有重啟概念。
「熱啟動」小程序沒有直接銷毀，而是進入后臺狀態：
「冷啟動」小程序需重新加載啟動：
這樣就會導致小程序版本更新后，如果客戶端存在舊版本的緩存，那就不會自動升級到新版本，而是維持舊版本的功能；所以需要在版本更新后，前端強制應用新版本并重啟。
第三方授權：作為小程序開發者，每次版本更新時都需要將代碼包上傳，并提交審核，比較麻煩。公司作為第三方開發者，例如有贊，可以支持一鍵授權功能——授權后的小程序能夠實現有新版本時自動提交審核，通過接口將小程序提交審核并發布，這樣對于同時管理開發多個小程序的第三方來講，省時省力。
內部H5頁面需要將鏈接配置為業務域名。好處是H5更新不需要審核，隨時可部署。弊處是如果該H5用于多個小程序，那么頁面會統一更新；外部H5頁面，如微信商城等，需要將鏈接配置為業務域名，并下載校驗文件，將校驗文件添加至該域名的根目錄下。業務域名規則為：每個小程序只能添加20個業務域名，一年只可修改50次業務域名。
小程序支持通過<web-view>組件接口打開公眾號文章，該公眾號必須和小程序關聯。
參考官方文檔：https://developers.weixin.qq.com/miniprogram/dev/component/web-view.html?search-key=webview
小程序和小程序之間可實現相互跳轉，且無需關聯同一公眾號。需獲得小程序的Appid及跳轉路徑，限制為每個小程序最多關聯10個其他小程序。
參考官方文擋：https://developers.weixin.qq.com/miniprogram/dev/api/wx.navigateToMiniProgram.html
需要對用戶發送服務通知（如評價提醒、預約成功）時，可以用特定的內容模版，主動向客戶發送消息，不支持廣告等營銷類消息。
模版內容：可自定義模版消息，不允許紅包、優惠、活動通知等營銷類內容。標題須以“通知”或“提醒”結尾，模版消息需要審核，模版添加成功后，即可通過接口調用模版ID。
參考官方文檔：https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1433751288
接入微信支付前，需開通微信支付且綁定微信商戶平臺，注意微信系統分為：
根據商戶類型不同，To B類的支付手續費不同，一般為千分之六。
退款是否收取手續費？——不收取
提現是否收取手續費？——不收取
注冊商戶平臺時的注意點：
當用戶發起提現或退款操作時，從企業的微信支付商戶賬戶中，支付對應金額至用戶的零錢賬戶。不是所有的商戶都有這個功能，開通要求為：選擇結算周期為“非T+0”商戶類目，否則需要滿足兩個條件：入駐滿 90 天，連續正常交易 30 天。
當結算周期到了，微信支付會將商戶號里面的未結算金額自動劃走，至商戶號綁定的銀行賬戶上面，并且收取約定的費率。問題是——當需要退款給用戶的時候，會發現賬戶上的錢全部被結算到銀行卡上，沒有錢退款給用戶，此時就需要關閉自動結算。然而，也不是所有商戶都有這個功能，要求：選擇結算周期為“T+0”商戶類目。
小程序一旦綁定微信支付商戶號，就沒辦法解綁，也就是沒有入口進行更換綁定的商戶號。
綁定方式有：
參考官方文檔：http://kf.qq.com/product/wechatpaymentmerchant.html#hid=hotfaq
標準：
限制點：
根據2018年微信公開課上公布的數據：小程序日活已達到1.7億，已上線58萬個小程序，企業和個人開發者超過100萬。
小程序開發門檻較低，有經驗的開發甚至可以一晚上迅速孵化出熱點小程序。因此，小程序生態愈加活躍，對于以上小程序迭代中的坑也好、規則也好，產品經理能夠在需求階段了解清除，能夠有效的提升效率，避免延緩迭代進度。
本文由 @Yanssie 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash, 基于CC0協議
家好，我是皮湯。最近業務調整，組內開啟了前端工程化方面的基建，我主要負責 CSS 技術選型這一塊，針對目前業界主流的幾套方案進行了比較完善的調研與比較，分享給大家。
目前整個 CSS 工具鏈、工程化領域的主要方案如下：
而我們技術選型的標準如下：
- 開發速度快
- 開發體驗友好
- 調試體驗友好
- 可維護性友好
- 擴展性友好
- 可協作性友好
- 體積小
- 有最佳實踐指導
目前主要需要對比的三套方案：
- Less/Sass + PostCSS 的純 CSS c側方案
- styled-components / emotion 的純 CSS-in-JS 側方案
- TailwindCSS 的以寫輔助類為主的 HTML 側方案
## 純 CSS 側方案
### 介紹與優點
> 維護狀態：一般
> Star 數：16.7K
> 支持框架：無框架限制
> 項目地址：https://github.com/less/less.js
Less/Sass + PostCSS 這種方案在目前主流的組件庫和企業級項目中使用很廣，如 ant-design 等
它們的主要作用如下：
- 為 CSS 添加了類似 JS 的特性，你也可以使用變量、mixin，寫判斷等
- 引入了模塊化的概念，可以在一個 less 文件中導入另外一個 less 文件進行使用
- 兼容標準，可以快速使用 CSS 新特性，兼容瀏覽器 CSS 差異等
這類工具能夠與主流的工程化工具一起使用，如 Webpack，提供對應的 loader 如 sass-loader，然后就可以在 React/Vue 項目中建 `.scss` 文件，寫 sass 語法，并導入到 React 組件中生效。
比如我寫一個組件在響應式各個斷點下的展示情況的 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;
}
}
```
或導入一些用于標準化瀏覽器差異的代碼：
```
@import "normalize.css";
// component 相關的其他代碼
```
### 不足
這類方案的一個主要問題就是，只是對 CSS 本身進行了增強，但是在幫助開發者如何寫更好的 CSS、更高效、可維護的 CSS 方面并沒有提供任何建議。
- 你依然需要自己定義 CSS 類、id，并且思考如何去用這些類、id 進行組合去描述 HTML 的樣式
- 你依然可能會寫很多冗余的 Less/Sass 代碼，然后造成項目的負擔，在可維護性方面也有巨大問題
### 優化
- 可以引入 CSS 設計規范：BEM 規范，來輔助用戶在整個網頁的 HTML 骨架以及對應的類上進行設計
- 可以引入 CSS Modules，將 CSS 文件進行 “作用域” 限制，確保在之后維護時，修改一個內容不會引起全局中其他樣式的效果
#### BEM 規范
B （Block）、E（Element）、M（Modifier），具體就是通過塊、元素、行為來定義所有的可視化功能。
拿設計一個 Button 為例：
```
/* Block */
.btn {}
/* 依賴于 Block 的 Element */
.btn__price {}
/* 修改 Block 風格的 Modifier */
.btn--orange {}
.btn--big {}
```
遵循上述規范的一個真實的 Button：
```
<a class="btn btn--big btn--orange" href="#">
<span class="btn__price"></span>
<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 (
<h1 className={style.title}>
Hello World
</h1>
);
};
```
```
.title {
composes: className;
color: red;
}
```
上述經過編譯會變成如下 hash 字符串：
```
<h1 class="_3zyde4l1yATCOkgn-DBWEL">
Hello World
</h1>
```
```
._3zyde4l1yATCOkgn-DBWEL {
color: red;
}
```
CSS Modules 可以與普通 CSS、Less、Sass 等結合使用。
## 純 JS 側方案
### 介紹與優點
> 維護狀態：一般
> Star 數：35.2K
> 支持框架：React ，通過社區支持 Vue 等框架
> 項目地址：https://github.com/styled-components/styled-components
使用 JS 的模板字符串函數，在 JS 里面寫 CSS 代碼，這帶來了兩個認知的改變：
- 不是在根據 HTML，然后去寫 CSS，而是站在組件設計的角度，為組件寫 CSS，然后應用組件的組合思想搭建大應用
- 自動提供類似 CSS Modules 的體驗，不用擔心樣式的全局污染問題
同時帶來了很多 JS 側才有的各種功能特性，可以讓開發者用開發 JS 的方式開發 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 的插值、組合等特性，然后應用 React 組件等組合思想，將組件與 CSS 進行細粒度綁定，讓 CSS 跟隨著組件一同進行組件化開發，同時提供和組件類似的模塊化特性，相比 Less/Sass 這一套，可以復用 JS 社區的最佳實踐等。
但是它仍然有一些不足：
- 仍然是是對 CSS 增強，提供非常大的靈活性，開發者仍然需要考慮如何去組織自己的 CSS
- 沒有給出一套 “有觀點” 的最佳實踐做法
- 在上層也缺乏基于 styled-components 進行復用的物料庫可進行參考設計和使用，導致在初始化使用時開發速度較低
- 在 JS 中寫 CSS，勢必帶來一些本屬于 JS 的限制，如 TS 下，需要對 Styled 的組件進行類型注釋
- 官方維護的內容只兼容 React 框架，Vue 和其他框架都由社區提供支持
整體來說不太符合團隊協作使用，需要人為總結最佳實踐和規范等。
### 優化
- 尋求一套寫 CSS 的最佳實踐和團隊協作規范
- 能夠擁有大量的物料庫或輔助類等，提高開發效率，快速完成應用開發
## 偏向 HTML 側方案
### 介紹與優點
> 維護狀態：積極
> Star 數：48.9K
> 支持框架：React、Vue、Svelte 等主流框架
> 項目地址：https://github.com/tailwindlabs/tailwindcss
典型的是 TailwindCSS，一個輔助類優先的 CSS 框架，提供如 `flex` 、`pt-4` 、`text-center` 、`rotate-90` 這樣實用的類名，然后基于這些底層的輔助類向上組合構建任何網站，而且只需要專注于為 HTML 設置類名即可。
一個比較形象的例子可以參考如下代碼：
```
<button class="btn btn--secondary">Decline</button>
<button class="btn btn--primary">Accept</button>
```
上述代碼應用 BEM 風格的類名設計，然后設計兩個按鈕，而這兩個類名類似主流組件庫里面的 Button 的不同狀態的設計，而這兩個類又是由更加基礎的 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;
}
```
上面的輔助類包含以下幾類：
- 設置文本相關： `text-base` 、`font-medium` 、`text-white` 、`text-black`
- 設置背景相關的：`bg-rose-500` 、`bg-gray-100`
- 設置間距相關的：`p-3`
- 設置邊角相關的：`rounded-lg`
通過 Tailwind 提供的 `@apply` 方法來對這些輔助類進行組合構建更上層的樣式類。
上述的最終效果展示如下：
可以看到 TailwindCSS 將我們開發網站的過程抽象成為使用 Figma 等設計軟件設計界面的過程，同時提供了一套用于設計的規范，相當于內置最佳實踐，如顏色、陰影、字體相關的內容，一個很形象的圖片可以說明這一點：
TailwindCSS 為我們規劃了一個元素可以設置的屬性，并且為每個屬性給定了一組可以設置的值，這些屬性+屬性值組合成一個有機的設計系統，非常便于團隊協作與共識，讓我們開發網站就像做設計一樣簡單、快速，但是整體風格又能保持一致。
TailwindCSS 同時也能與主流組件庫如 React、Vue、Svelte 結合，融入基于組件的 CSS 設計思想，但又只需要修改 HTML 上的類名，如我們設計一個食譜組件：
```
// 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 (
<div className="divide-y divide-gray-100">
<Nav>
<NavItem href="/featured" isActive>Featured</NavItem>
<NavItem href="/popular">Popular</NavItem>
<NavItem href="/recent">Recent</NavItem>
</Nav>
<List>
{recipes.map((recipe) => (
<ListItem key={recipe.id} recipe={recipe} />
))}
</List>
</div>
)
}
// Nav.js
export default function Nav({ children }) {
return (
<nav className="p-4">
<ul className="flex space-x-2">
{children}
</ul>
</nav>
)
}
// NavItem.js
export default function NavItem({ href, isActive, children }) {
return (
<li>
<a
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 (
<ul className="divide-y divide-gray-100">
{children}
</ul>
)
}
//ListItem.js
export default function ListItem({ recipe }) {
return (
<article className="p-4 flex space-x-4">
<img src={recipe.image} alt="" className="flex-none w-18 h-18 rounded-lg object-cover bg-gray-100" width="144" height="144" />
<div className="min-w-0 relative flex-auto sm:pr-20 lg:pr-0 xl:pr-20">
<h2 className="text-lg font-semibold text-black mb-0.5">
{recipe.title}
</h2>
<dl className="flex flex-wrap text-sm font-medium whitespace-pre">
<div>
<dt className="sr-only">Time</dt>
<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>
<div className="flex-none w-full mt-0.5 font-normal">
<dt className="inline">By</dt>{' '}
<dd className="inline text-black">{recipe.author}</dd>
</div>
<div class="absolute top-0 right-0 rounded-full bg-amber-50 text-amber-900 px-2 py-0.5 hidden sm:flex lg:hidden xl:flex items-center space-x-1">
<dt className="text-amber-500">
<span className="sr-only">Rating</span>
<svg width="16" height="20" fill="currentColor">
<path d="M7.05 3.691c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.372 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.539 1.118l-2.8-2.034a1 1 0 00-1.176 0l-2.8 2.034c-.783.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.363-1.118L.98 9.483c-.784-.57-.381-1.81.587-1.81H5.03a1 1 0 00.95-.69L7.05 3.69z" />
</svg>
</dt>
<dd>{recipe.rating}</dd>
</div>
</dl>
</div>
</article>
)
}
```
上述食譜的效果如下：
可以看到我們無需寫一行 CSS，而是在 HTML 里面應用各種輔助類，結合 React 的組件化設計，既可以輕松完成一個非?，F代化且好看的食譜組件。
除了上面的特性，TailwindCSS 在響應式、新特性支持、Dark Mode、自定義配置、自定義新的輔助類、IDE 方面也提供非常優秀的支持，除此之外還有基于 TailwindCSS 構建的物料庫 Tailwind UI ，提供各種各樣成熟、好看、可用于生產的物料庫：
因為需要自定的 CSS 不多，而需要自定義的 CSS 可以定義為可復用的輔助類，所以在可維護性方面也是極好的。
### 不足
- 因為要引入一個額外的運行時，TailwindCSS 輔助類到 CSS 的編譯過程，而隨著組件越來越多，需要編譯的工作量也會變大，所以速度會有影響
- 過于底層，相當于給了用于設計的最基礎的指標，但是如果我們想要快速設計網站，那么可能還需要一致的、更加上層的組件庫
- 相當于引入了一套框架，具有一定的學習成本和使用成本
### 優化
- Tailwind 2.0 支持 [JIT](https://blog.tailwindcss.com/tailwindcss-2-1 "JIT")，可以大大提升編譯速度，可以考慮引入
- 基于 TailwindCSS，設計一套符合自身風格的上層組件庫、物料庫，便于更加快速開發
- 提前探索、學習和總結一套教程與開發最佳實踐
- 探索 styled-components 等結合 TailwindCSS 的開發方式
## 參考鏈接
- [CSS 工程化發展歷程](https://bytedance.feishu.cn/docs/doccnTRF0OZtJMgKuo3y0hIDMbc# "CSS 工程化發展歷程")
以上便是本次分享的全部內容，希望對你有所幫助^_^
喜歡的話別忘了 分享、點贊、收藏 三連哦~
歡迎關注公眾號 程序員巴士，來自字節、蝦皮、招銀的三端兄弟，分享編程經驗、技術干貨與職業規劃，助你少走彎路進大廠。
o語言中的鎖簡單易用，本文整理一下鎖的實現原理。
Golang中鎖有兩種，互斥鎖Mutex和讀寫互斥鎖RWMutex，互斥鎖也叫讀鎖，讀寫鎖也叫讀鎖，相互之間的關系為：
互斥鎖和讀寫鎖在使用上沒有很大區別
但兩者使用場景不同：
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值是順序增加的，而使用讀寫互斥鎖，數據則是無序的。
講鎖的具體實現原理之前，需要先復習幾個基礎知識：進程同步、信號量和自旋。
進程同步本質上是靠控制對臨界區的訪問權限實現的。
同步機制規則
(1) 空閑讓進。當無進程處于臨界區時，表明臨界資源處于空閑狀態，應允許一個請求進入臨界區的進程立即進入自己的臨界區，以有效地利用臨界資源。
(2) 忙則等待。當已有進程進入臨界區時，表明臨界資源正在被訪問，因而其它試圖進 入臨界區的進程必須等待，以保證對臨界資源的互斥訪問。
(3) 有限等待。對要求訪問臨界資源的進程，應保證在有限時間內能進入自己的臨界區， 以免陷入“死等”狀態。
(4) 讓權等待。當進程不能進入自己的臨界區時，應立即釋放處理機，以免進程陷入“忙等”狀態。
這個規則和現實一致：如果有空閑我就可以用吧（空閑讓進）；如果不空閑，為了有序我可以等待（忙則等待）；我等待的時候沒別的事情可以做，那可以去一邊休息吧（讓權等待）；你們不能讓我老等著吧（有限等待）；
1965 年，荷蘭學者 Dijkstra 提出的信號量(Semaphores)機制是一種卓有成效的進程同步工具。Dijkstra，YYDS。
信號量現在已發展為如下四種類型：
雖然信號量有不同類型，但核心是對：一個用于表示資源數目的整型量 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；
同步機制規則里有讓權等待，自旋其實就是說在進程不能進入自己的臨界區時是如何處理的。
加鎖時，如果發現該鎖當前由其他協程持有，嘗試加鎖的協程并不是馬上轉入阻塞，而是會持續的探測鎖是否被釋放，這個過程即為自旋過程。自旋時間很短，但如果在自旋過程中發現鎖已被釋放，那么協程可以立即獲取鎖。
自旋過程為先檢查是否可以加鎖，如果不可以，執行CPU PAUSE指令，CPU對該指令什么都不做，一般為30個時鐘周期。PAUSE執行后，再檢查是否可以加鎖，循環往復。
在這個過程中，進程仍然是執行狀態，不是睡眠狀態。
自旋主要為了更加高效，減少損耗。自旋的優勢是更充分的利用CPU，盡量避免協程切換。因為當前申請加鎖的協程擁有CPU，如果經過短時間的自旋可以獲得鎖，當前協程可以繼續運行，不必進入阻塞狀態。
自旋不能隨便使用，否則不但發揮不了優勢，還會帶來更多損耗，舉個簡單的例子：如果自旋次數不限制，而獲得鎖的進程很長時間后才釋放鎖，則自旋的進程這段時間CPU完全浪費了。
所以使用自旋，一定要滿足一下條件：
自旋有個特性，無視正在排隊等待加鎖的進程，在自旋過程中，獲取到鎖便可加鎖，類似于插隊。
所以使用自旋會引發問題：極端情況下，很多進程正排隊等待加鎖，此時有進程剛到，開始自旋加鎖，如果成功，該進程便插隊成功加鎖。如果此時不斷有進程自旋加鎖，則在排隊的進程將長時間無法獲取到鎖。
一般解決方案為：鎖添加饑餓狀態，該狀態下不允許自旋。
Mutex結構體如下：
// A Mutex must not be copied after first use.
// Mutex被使用后，不可以將其復制。(意思是不能復制值，可以做成引用復制)
// 復制容易導致非預期的死鎖，https://mozillazg.com/2019/04/notes-about-go-lock-mutex.html#hidcopy
type Mutex struct {
state int32
sema uint32
}
state是32位的整型變量，內部實現時把該變量分成四份，用于記錄Mutex的四種狀態。
const (
mutexLocked = 1 << iota //值1
mutexWoken //值2
mutexStarving //值4
)
Locked: 表示該Mutex是否已被鎖定，0：沒有鎖定 1：已被鎖定。
Woken: 表示是否有協程已被喚醒，0：沒有協程喚醒 1：已有協程喚醒，正在加鎖過程中。釋放鎖時，如果正常模式下，不會再喚醒其它協程。
Starving：表示該Mutex是否處理饑餓狀態， 0：沒有饑餓 1：饑餓狀態，說明有協程阻塞了超過1ms。
Waiter: 表示阻塞等待鎖的協程個數，協程解鎖時根據此值來判斷是否需要釋放信號量
協程之間搶鎖實際上是搶給Locked賦值的權利，能給Locked域置1，就說明搶鎖成功。搶不到的話就阻塞等待
Mutex.sema信號量，一旦持有鎖的協程解鎖，等待的協程會依次被喚醒。
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.
互斥量有兩種模式：正常模式和饑餓模式。
正常模式：正常模式下等待的協程按照先入先出排列，當一個協程被喚醒后并不是直接擁有鎖，該協程需要和剛剛到達的協程一起競爭鎖的所有權。新到的協程有個優勢，那就是它已經在CPU上運行了，而且新到的協程可能有很多，所以被喚醒的協程極有可能搶占不到鎖。在這種情況下，被喚醒的協程會被放置于等待隊列的隊頭。如果等待的協程超過1ms內沒有獲取到鎖，將會把鎖置為饑餓模式。
饑餓模式：在饑餓模式下，解鎖的協程會將鎖的所有權直接交給等待隊列中位于隊頭的協程。正好解鎖的那一刻有新的協程到達，新到達的協程也不會嘗試自旋獲取鎖。相反，他們會將自己置于等待隊列的隊尾。
如果等待隊列中的協程獲取到鎖，它會查看
(1)自己是否是等待隊列中最后一個協程
(2)自己等待的時間是否小于1ms
如果有任意一個條件滿足，將會將鎖改為普通模式。
一般認為普通模式會有更好的性能，因為即使有等待的協程，新的協程可以連續獲取到鎖。饑餓模式能夠防止等待協程長時間獲取不到鎖。
// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
// 如果鎖已經被占用了，則將調用Lock的協程阻塞，知道鎖被釋放
func (m *Mutex) Lock() {
// Fast path: grab unlocked mutex.
// 如果鎖即沒被占用、也不是饑餓狀態、也沒有喚醒協程、也沒有等待的協程，直接加鎖成功
// 這是比較完美的一種狀態
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.
// 如果是正常模式且鎖被搶占了，自己符合自旋條件，就自旋
// 因為按照規定，饑餓模式下需要保證等待隊列中的協程能夠獲得鎖的所有權，防止等待隊列餓死
// 如果鎖變為饑餓狀態或者已經解鎖了，或者不符合自旋條件了就結束自旋
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.
// 如果等待隊列有協程、鎖沒有設置喚醒狀態，就努力設置喚醒狀態
// 這么做的好處是，當鎖解鎖的時候，不會去喚醒已經阻塞的協程，保證自己更大概率獲取到鎖
if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
awoke = true
}
runtime_doSpin()
iter++
old = m.state
continue
}
// 此處說明鎖變為饑餓狀態或者已經解鎖了，或者不符合自旋條件了（仍為鎖定狀態）
// 鎖狀態包含-饑餓鎖定、饑餓未鎖定、正常鎖定、正常未鎖定
// 獲取鎖最新的狀態
new := old
// Don't try to acquire starving mutex, new arriving goroutines must queue.
// 如果是正常狀態，嘗試加鎖。饑餓狀態下要出讓競爭權利，肯定不能加鎖的
if old&mutexStarving == 0 {
new |= mutexLocked
}
// 如果鎖還是被占用的或者鎖是饑餓狀態，只能將自己放到等待隊列上
// 到了這個階段，遇到這些狀態，協程只能躺平。饑餓狀態要出讓競爭權利
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.
// 如果自身已經到饑餓狀態了，而且鎖是被占用情況下，將鎖改為饑餓狀態
// 鎖未被占用不能改為饑餓模式，是因為如果鎖沒有被占用，但是鎖是饑餓狀態，那應該有等待隊列。
// 如果鎖未被占用卻改為饑餓狀態，違背了這個條件。(不是很明白這句話)
if starving && old&mutexLocked != 0 {
new |= mutexStarving
}
// 如果該協程設置鎖的喚醒狀態，需要將喚醒狀態進行重置。
// 因為改協程要么獲得了鎖、要么進入休眠，都和喚醒狀態無關了
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) 等待加一，狀態待定，加鎖 -> 加到等待隊列
// (0,0)正常且未鎖定 -> (+0,0 ,1) 等待不變，正常狀態，加鎖 -> 加鎖成功
// (1,1)饑餓且已鎖定 -> (+1,1?,1) 等待加一，饑餓待定，加鎖 -> 加到等待隊列
// (1,0)饑餓且未鎖定 -> (+1,1 ,0) 等待加一，饑餓狀態，不加鎖 -> 加到等待隊列
if atomic.CompareAndSwapInt32(&m.state, old, new) {//如果CAS成功
//如果鎖為未鎖定且正常狀態，表明占有鎖成功，加鎖操作完畢
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()
}
// 走到此處，說明協程沒有獲取到鎖，調用runtime_SemacquireMutex，將該協程掛起
// waitStartTime能夠判斷該協程是新來的還是被喚醒的
// 如果是新來的，則加入隊列尾部，等待喚醒，queueLifo=false
// 如果是從等待隊列中喚醒的，則加入隊列頭部，queueLifo=true
// 如果后面該協程被喚醒，就從該位置繼續往下執行
runtime_SemacquireMutex(&m.sema, queueLifo, 1)
// 此刻說明該協程被喚醒了
// 判斷該協程是否長時間沒有獲取到鎖，如果是的話，就是饑餓的協程
starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
// 協程被掛起的時間有點長，需要重新獲取一下當前鎖的狀態
old = m.state
// 表示當前是饑餓狀態的情況。按照設定，饑餓狀態下，被喚醒的協程直接獲得鎖。
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.
// 饑餓狀態下，我被喚醒，結果發現鎖沒釋放、喚醒值是1、等待列表沒有協程了（不把我算作協程了）
// 不符合設定，果斷有問題啊
if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
throw("sync: inconsistent mutex state")
}
// 值是7，因為此時鎖狀態為未鎖定，使用7可以達到等待數量減一，同時將鎖設置為鎖定的效果
delta := int32(mutexLocked - 1<<mutexWaiterShift)
// 如果喚醒等待隊列的協程不饑餓、或者這個協程是等待隊列中最后一個協程，就改為正常狀態
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
}
// 將鎖狀態設置為等待數量減一，同時設置為鎖定。加鎖成功
// 這個計算方法太秀了
atomic.AddInt32(&m.state, delta)
break
}
// 本協程千真萬確就是被系統喚醒的協程
awoke = true
// 自旋次數重置為0
iter = 0
} else { //如果CAS失敗，則重新開始
old = m.state
}
}
if race.Enabled {
race.Acquire(unsafe.Pointer(m))
}
}
// 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.
// 加鎖和解鎖可以不是同一個協程
func (m *Mutex) Unlock() {
if race.Enabled { //默認是false
_ = m.state
race.Release(unsafe.Pointer(m))
}
// Fast path: drop lock bit.
// 不是饑餓狀態，沒有等待的協程、沒有喚醒，直接解鎖完畢
new := atomic.AddInt32(&m.state, -mutexLocked)
// 說明可能為饑餓狀態、有等待協程、有喚醒的協程，事情沒處理完，還得繼續處理
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.
// 如果等待列表里沒有協程了，或者已經有喚醒的協程了，就無需浪費精力喚醒其它協程了
if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
return
}
// Grab the right to wake someone.
// 等待協程數量減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.
// 饑餓模式下，直接將鎖的所有權交給等待隊列中的第一個
// 注意：鎖的locked位沒有被設置，喚醒的協程后面會進行設置
// 盡管沒有設置locked位，但是在饑餓模式下，新來的協程也是無法獲取到鎖的。
runtime_Semrelease(&m.sema, true, 1)
}
}
【runtime_canSpin】：在 src/runtime/proc.go 中被實現 sync_runtime_canSpin；表示是否可以保守的自旋，golang中自旋鎖并不會一直自旋下去，在runtime包中runtime_canSpin方法做了一些限制, 傳遞過來的iter大等于4或者cpu核數小等于1，最大邏輯處理器大于1，至少有個本地的P隊列，并且本地的P隊列可運行G隊列為空。
【runtime_doSpin】：在 src/runtime/proc.go 中被實現 sync_runtime_doSpin；表示 會調用procyield函數， 該函數也是匯編語言實現。函數內部循環調用PAUSE指令。PAUSE指令什么都不做， 但是會消耗CPU時間，在執行PAUSE指令時，CPU不會對它做不必要的優化。
【runtime_SemacquireMutex】：在 src/runtime/sema.go 中被實現 sync_runtime_SemacquireMutex；表示通過信號量阻塞當前協程 。
【runtime_Semrelease】: 在src/runtime/sema.go 中被實現 sync_runtime_Semrelease。表示通過信號量解除當前協程阻塞。
https://www.processon.com/view/link/60f4e1021e085376da5c05f8
Go互斥鎖實現邏輯很復雜，能夠看到大量的性能優化方面的代碼，所以導致整個邏輯很難理解。大家即使看了注釋和流程圖，理解起來應該還是會有些困難。我的建議是，一是搞懂lock、woken、starving所代表的功能，二是不是要1.13版本的鎖實現，可以看早期實現，會更加簡單一些。
本來以為寫鎖的實現會很快能完成，結果看這一兩百行代碼用了差不多一個星期。個人也不太建議看1.13鎖的具體實現，太過于繁雜了?？梢钥匆幌耯ttps://www.cnblogs.com/niniwzw/p/3153955.html，講了鎖的演變。
更容易讓大家理解的方式是使用狀態機，將加鎖和寫鎖操作都放入狀態機中，但鎖狀態分四部分，加上各種操作，繪制起來比較耗時，如果大家有興趣可以繪制一下。
寫這篇文章的時候，有些資料查的大學教程《計算機操作系統》，發覺這些書真是好書，不但準確而且易懂，以前都是死記硬背，現在感覺簡直是寶書。
讀寫鎖另起一篇文章寫吧，這篇已經太長了，寫不動了。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
