整合營銷服務(wù)商

          電腦端+手機端+微信端=數(shù)據(jù)同步管理

          免費咨詢熱線:

          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ī)則,遵守微信的克制,五花八門的小程序一個個冒出頭來,小程序成為追逐線上紅利的絕佳土壤。

          小程序的上線流程:

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

          一、小程序一鍵更新

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

          「熱啟動」小程序沒有直接銷毀,而是進入后臺狀態(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. 小程序與商戶號綁定

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

          綁定方式有:

          1. 利用現(xiàn)有小程序作為申請入口,申請一個新的微信支付;
          2. 綁定已有的微信支付商戶號。推薦不同的業(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:

          ```

          <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)的物料庫:

          ![](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)系為:

          1. 寫鎖需要阻塞寫鎖:一個協(xié)程擁有寫鎖時,其他協(xié)程寫鎖定需要阻塞
          2. 寫鎖需要阻塞讀鎖:一個協(xié)程擁有寫鎖時,其他協(xié)程讀鎖定需要阻塞
          3. 讀鎖需要阻塞寫鎖:一個協(xié)程擁有讀鎖時,其他協(xié)程寫鎖定需要阻塞
          4. 讀鎖不能阻塞讀鎖:一個協(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)的。

          1. 臨界資源:把在一段時間內(nèi)只允許一個進程訪問的資源稱為臨界資源或獨占資源。計算機系統(tǒng)中的大多數(shù)物理設(shè)備,以及某些軟件中所用的棧、變量和表格,都屬于臨界資源, 它們要求被互斥地共享
          2. 臨界區(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ā)展為如下四種類型:

          1. 整型信號量
          2. 記錄型信號量
          3. AND型信號量
          4. 信號量集

          雖然信號量有不同類型,但核心是對:一個用于表示資源數(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)用

          1. 利用信號量實現(xiàn)進程互斥為使多個進程能互斥地訪問某臨界資源,只須為該資源設(shè)置一互斥信號量 mutex,并設(shè)其初始值為 1,然后將各進程訪問該資源的臨界區(qū)(critical section)置于 wait(mutex)和 signal(mutex)操作之間即可。
          2. 利用信號量實現(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)太長了,寫不動了。

          資料

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

          主站蜘蛛池模板: 天天躁日日躁狠狠躁一区| 亚洲av乱码中文一区二区三区 | 日韩国产一区二区| 日本不卡一区二区视频a| 国产精品一区二区三区久久| 亚洲一区二区在线免费观看| 久久一区二区免费播放| 国产综合精品一区二区| 国产精品一区二区毛卡片| 久久99国产精品一区二区| 精品一区二区三区免费视频| 国产精品亚洲一区二区在线观看 | 亚洲AV网一区二区三区| 精品国产鲁一鲁一区二区| 久久精品一区二区免费看| 国产午夜精品一区二区三区漫画| 日韩精品一区二区午夜成人版 | 亚洲国产精品一区二区第一页 | 亚洲第一区二区快射影院| 91视频一区二区| 国产伦理一区二区| 久久亚洲一区二区| 无码国产精品一区二区免费16| 成人一区二区免费视频| 曰韩精品无码一区二区三区| 日韩AV无码一区二区三区不卡毛片| 亚洲av片一区二区三区| 无人码一区二区三区视频 | 伊人久久精品一区二区三区 | 国产精品久久久久一区二区| 最新中文字幕一区| 男人的天堂精品国产一区| 精品视频在线观看一区二区| 人妻无码一区二区三区四区| 区三区激情福利综合中文字幕在线一区亚洲视频1 | 美女视频一区二区三区| 久久影院亚洲一区| 日韩精品中文字幕无码一区 | 濑亚美莉在线视频一区| 无码AV一区二区三区无码| 国产日韩精品一区二区三区在线|