程序作為產(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ī)則,遵守微信的克制,五花八門的小程序一個個冒出頭來,小程序成為追逐線上紅利的絕佳土壤。
小程序的上線流程:
小程序的重啟機制:小程序沒有重啟概念。
「熱啟動」小程序沒有直接銷毀,而是進入后臺狀態(tài):
「冷啟動」小程序需重新加載啟動:
這樣就會導(dǎo)致小程序版本更新后,如果客戶端存在舊版本的緩存,那就不會自動升級到新版本,而是維持舊版本的功能;所以需要在版本更新后,前端強制應(yīng)用新版本并重啟。
第三方授權(quán):作為小程序開發(fā)者,每次版本更新時都需要將代碼包上傳,并提交審核,比較麻煩。公司作為第三方開發(fā)者,例如有贊,可以支持一鍵授權(quán)功能——授權(quán)后的小程序能夠?qū)崿F(xiàn)有新版本時自動提交審核,通過接口將小程序提交審核并發(fā)布,這樣對于同時管理開發(fā)多個小程序的第三方來講,省時省力。
內(nèi)部H5頁面需要將鏈接配置為業(yè)務(wù)域名。好處是H5更新不需要審核,隨時可部署。弊處是如果該H5用于多個小程序,那么頁面會統(tǒng)一更新;外部H5頁面,如微信商城等,需要將鏈接配置為業(yè)務(wù)域名,并下載校驗文件,將校驗文件添加至該域名的根目錄下。業(yè)務(wù)域名規(guī)則為:每個小程序只能添加20個業(yè)務(wù)域名,一年只可修改50次業(yè)務(wù)域名。
小程序支持通過<web-view>組件接口打開公眾號文章,該公眾號必須和小程序關(guān)聯(lián)。
參考官方文檔:https://developers.weixin.qq.com/miniprogram/dev/component/web-view.html?search-key=webview
小程序和小程序之間可實現(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
需要對用戶發(fā)送服務(wù)通知(如評價提醒、預(yù)約成功)時,可以用特定的內(nèi)容模版,主動向客戶發(fā)送消息,不支持廣告等營銷類消息。
模版內(nèi)容:可自定義模版消息,不允許紅包、優(yōu)惠、活動通知等營銷類內(nèi)容。標題須以“通知”或“提醒”結(jié)尾,模版消息需要審核,模版添加成功后,即可通過接口調(diào)用模版ID。
參考官方文檔:https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1433751288
接入微信支付前,需開通微信支付且綁定微信商戶平臺,注意微信系統(tǒng)分為:
根據(jù)商戶類型不同,To B類的支付手續(xù)費不同,一般為千分之六。
退款是否收取手續(xù)費?——不收取
提現(xiàn)是否收取手續(xù)費?——不收取
注冊商戶平臺時的注意點:
當用戶發(fā)起提現(xiàn)或退款操作時,從企業(yè)的微信支付商戶賬戶中,支付對應(yīng)金額至用戶的零錢賬戶。不是所有的商戶都有這個功能,開通要求為:選擇結(jié)算周期為“非T+0”商戶類目,否則需要滿足兩個條件:入駐滿 90 天,連續(xù)正常交易 30 天。
當結(jié)算周期到了,微信支付會將商戶號里面的未結(jié)算金額自動劃走,至商戶號綁定的銀行賬戶上面,并且收取約定的費率。問題是——當需要退款給用戶的時候,會發(fā)現(xiàn)賬戶上的錢全部被結(jié)算到銀行卡上,沒有錢退款給用戶,此時就需要關(guān)閉自動結(jié)算。然而,也不是所有商戶都有這個功能,要求:選擇結(jié)算周期為“T+0”商戶類目。
小程序一旦綁定微信支付商戶號,就沒辦法解綁,也就是沒有入口進行更換綁定的商戶號。
綁定方式有:
參考官方文檔:http://kf.qq.com/product/wechatpaymentmerchant.html#hid=hotfaq
標準:
限制點:
根據(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:
```
<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;
}
```
上述經(jīng)過編譯會變成如下 hash 字符串:
```
<h1 class="_3zyde4l1yATCOkgn-DBWEL">
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 (
<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 里面應(yīng)用各種輔助類,結(jié)合 React 的組件化設(shè)計,既可以輕松完成一個非常現(xiàn)代化且好看的食譜組件。
除了上面的特性,TailwindCSS 在響應(yīng)式、新特性支持、Dark Mode、自定義配置、自定義新的輔助類、IDE 方面也提供非常優(yōu)秀的支持,除此之外還有基于 TailwindCSS 構(gòu)建的物料庫 Tailwind UI ,提供各種各樣成熟、好看、可用于生產(chǎn)的物料庫:

因為需要自定的 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)系為:
互斥鎖和讀寫鎖在使用上沒有很大區(qū)別
但兩者使用場景不同:
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ù)則是無序的。
講鎖的具體實現(xiàn)原理之前,需要先復(fù)習幾個基礎(chǔ)知識:進程同步、信號量和自旋。
進程同步本質(zhì)上是靠控制對臨界區(qū)的訪問權(quán)限實現(xiàn)的。
同步機制規(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)等待);你們不能讓我老等著吧(有限等待);
1965 年,荷蘭學(xué)者 Dijkstra 提出的信號量(Semaphores)機制是一種卓有成效的進程同步工具。Dijkstra,YYDS。
信號量現(xiàn)在已發(fā)展為如下四種類型:
雖然信號量有不同類型,但核心是對:一個用于表示資源數(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;
同步機制規(guī)則里有讓權(quán)等待,自旋其實就是說在進程不能進入自己的臨界區(qū)時是如何處理的。
加鎖時,如果發(fā)現(xiàn)該鎖當前由其他協(xié)程持有,嘗試加鎖的協(xié)程并不是馬上轉(zhuǎn)入阻塞,而是會持續(xù)的探測鎖是否被釋放,這個過程即為自旋過程。自旋時間很短,但如果在自旋過程中發(fā)現(xiàn)鎖已被釋放,那么協(xié)程可以立即獲取鎖。
自旋過程為先檢查是否可以加鎖,如果不可以,執(zhí)行CPU PAUSE指令,CPU對該指令什么都不做,一般為30個時鐘周期。PAUSE執(zhí)行后,再檢查是否可以加鎖,循環(huán)往復(fù)。
在這個過程中,進程仍然是執(zhí)行狀態(tài),不是睡眠狀態(tài)。
自旋主要為了更加高效,減少損耗。自旋的優(yōu)勢是更充分的利用CPU,盡量避免協(xié)程切換。因為當前申請加鎖的協(xié)程擁有CPU,如果經(jīng)過短時間的自旋可以獲得鎖,當前協(xié)程可以繼續(xù)運行,不必進入阻塞狀態(tài)。
自旋不能隨便使用,否則不但發(fā)揮不了優(yōu)勢,還會帶來更多損耗,舉個簡單的例子:如果自旋次數(shù)不限制,而獲得鎖的進程很長時間后才釋放鎖,則自旋的進程這段時間CPU完全浪費了。
所以使用自旋,一定要滿足一下條件:
自旋有個特性,無視正在排隊等待加鎖的進程,在自旋過程中,獲取到鎖便可加鎖,類似于插隊。
所以使用自旋會引發(fā)問題:極端情況下,很多進程正排隊等待加鎖,此時有進程剛到,開始自旋加鎖,如果成功,該進程便插隊成功加鎖。如果此時不斷有進程自旋加鎖,則在排隊的進程將長時間無法獲取到鎖。
一般解決方案為:鎖添加饑餓狀態(tài),該狀態(tài)下不允許自旋。
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是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é)程會依次被喚醒。
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é)程長時間獲取不到鎖。
// 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))
}
}
// 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)
}
}
【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é)程阻塞。
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),會更加簡單一些。
本來以為寫鎖的實現(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)太長了,寫不動了。
*請認真填寫需求信息,我們會在24小時內(nèi)與您取得聯(lián)系。