5个要点，避免踩坑小程序

程序作为产品形态的一种，比App轻量、比Web网页简洁，但由于依赖微信生态，必须遵守微信生态的规则。作为产品经理，参与小程序产品迭代已有四个月，踩过不少坑；经历几次迭代，对小程序规则有了一定了解。希望在这里能够总结小程序这种产品形态，有哪些注意点。

毫无约束的自由往往无法创新，在一定规则内的自由才是真正的自由。而微信生态就是小程序必须遵守的规则，遵守微信的克制，五花八门的小程序一个个冒出头来，小程序成为追逐线上红利的绝佳土壤。

小程序的上线流程：

小程序开发：迭代流程和App产品相同，更加轻量化。要注意的是，每个小程序都有唯一的Appid和Appsecret，后者只有小程序管理员可查看。
开发版：将代码上传微信，可用于开发大佬测试效果。
体验版：可通过二维码分享体验，需要管理员为微信号添加体验权限。
线上版：将体验版提交微信审核，通过后即可上线正式版小程序，此时可在微信搜索到小程序，审核时间大约半天。

一、小程序一键更新

小程序的重启机制：小程序没有重启概念。

「热启动」小程序没有直接销毁，而是进入后台状态：

点击右上角胶囊按钮关闭小程序；
Home键离开小程序。

「冷启动」小程序需重新加载启动：

用户首次打开小程序；
当小程序进入后台状态，超过一定时间（5分钟），被微信主动销毁后再次打开；
收到系统内存告警，小程序主动销毁。

这样就会导致小程序版本更新后，如果客户端存在旧版本的缓存，那就不会自动升级到新版本，而是维持旧版本的功能；所以需要在版本更新后，前端强制应用新版本并重启。

第三方授权：作为小程序开发者，每次版本更新时都需要将代码包上传，并提交审核，比较麻烦。公司作为第三方开发者，例如有赞，可以支持一键授权功能——授权后的小程序能够实现有新版本时自动提交审核，通过接口将小程序提交审核并发布，这样对于同时管理开发多个小程序的第三方来讲，省时省力。

二、小程序跳转类型

1. H5

内部H5页面需要将链接配置为业务域名。好处是H5更新不需要审核，随时可部署。弊处是如果该H5用于多个小程序，那么页面会统一更新；外部H5页面，如微信商城等，需要将链接配置为业务域名，并下载校验文件，将校验文件添加至该域名的根目录下。业务域名规则为：每个小程序只能添加20个业务域名，一年只可修改50次业务域名。

2. 公众号文章

小程序支持通过<web-view>组件接口打开公众号文章，该公众号必须和小程序关联。

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

3. 小程序

小程序和小程序之间可实现相互跳转，且无需关联同一公众号。需获得小程序的Appid及跳转路径，限制为每个小程序最多关联10个其他小程序。

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

三、推送微信服务通知

需要对用户发送服务通知（如评价提醒、预约成功）时，可以用特定的内容模版，主动向客户发送消息，不支持广告等营销类消息。

模版内容：可自定义模版消息，不允许红包、优惠、活动通知等营销类内容。标题须以“通知”或“提醒”结尾，模版消息需要审核，模版添加成功后，即可通过接口调用模版ID。

只有在用户触发某种行为后，才能主动下发消息给用户，期限为7天；不允许在用户没做任何操作或未经用户同意接收的前提下，主动下发消息给用户；
模板消息可以在模板库中选择，可以申请添加，一个月可以申请三条；
如需跳转到小程序，只能有一个跳转入口，模版中固定有拒收通知选项。

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

四、接入微信支付

接入微信支付前，需开通微信支付且绑定微信商户平台，注意微信系统分为：

微信商户平台
微信开放平台（App支付）
微信公众平台：订阅号、服务号、小程序

根据商户类型不同，To B类的支付手续费不同，一般为千分之六。

退款是否收取手续费？——不收取

提现是否收取手续费？——不收取

注册商户平台时的注意点：

1. 企业付款到零钱

当用户发起提现或退款操作时，从企业的微信支付商户账户中，支付对应金额至用户的零钱账户。不是所有的商户都有这个功能，开通要求为：选择结算周期为“非T+0”商户类目，否则需要满足两个条件：入驻满 90 天，连续正常交易 30 天。

2. 自动结算

当结算周期到了，微信支付会将商户号里面的未结算金额自动划走，至商户号绑定的银行账户上面，并且收取约定的费率。问题是——当需要退款给用户的时候，会发现账户上的钱全部被结算到银行卡上，没有钱退款给用户，此时就需要关闭自动结算。然而，也不是所有商户都有这个功能，要求：选择结算周期为“T+0”商户类目。

3. 小程序与商户号绑定

小程序一旦绑定微信支付商户号，就没办法解绑，也就是没有入口进行更换绑定的商户号。

绑定方式有：

利用现有小程序作为申请入口，申请一个新的微信支付；
绑定已有的微信支付商户号。推荐不同的业务最好分开结算，这样便于财务进行对账。如有需要，可以绑定能关闭自动结算的微信支付商户号，能省去许多麻烦。

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

五、通用注意点

标准：

小程序顶部导航栏标题：iOS居中，安卓居左；
有关注公众号入口（在右上角选择相关公众号可见）；
可以用腾讯地图定位；
安卓的小程序能放在桌面，iOS不能；
客服不能支持同时回复文字和图片，支持图文消息。

限制点：

小程序不能长按扫码识别；
iOS 系统下，小程序不支持虚拟支付（VIP会员、充值、录制课程）；
不能朋友圈；
小程序代码包不超过2M；
获取用户的微信头像、昵称、电话等信息，需用户同意。

六、小结

根据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：

```

<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;

}

```

上述经过编译会变成如下 hash 字符串：

```

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 (

<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 里面应用各种辅助类，结合 React 的组件化设计，既可以轻松完成一个非常现代化且好看的食谱组件。

除了上面的特性，TailwindCSS 在响应式、新特性支持、Dark Mode、自定义配置、自定义新的辅助类、IDE 方面也提供非常优秀的支持，除此之外还有基于 TailwindCSS 构建的物料库 Tailwind UI ，提供各种各样成熟、好看、可用于生产的物料库：

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

因为需要自定的 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，互斥锁也叫读锁，读写锁也叫读锁，相互之间的关系为：

写锁需要阻塞写锁：一个协程拥有写锁时，其他协程写锁定需要阻塞
写锁需要阻塞读锁：一个协程拥有写锁时，其他协程读锁定需要阻塞
读锁需要阻塞写锁：一个协程拥有读锁时，其他协程写锁定需要阻塞
读锁不能阻塞读锁：一个协程拥有读锁时，其他协程也可以拥有读锁

1.使用

互斥锁和读写锁在使用上没有很大区别

互斥锁使用Lock()进行加锁，使用Unlock()进行解锁
读写锁使用RLock()加读锁，使用RUnlock()进行解读锁；使用Lock()加写锁，使用Unlock解写锁，和互斥锁功能一致；

但两者使用场景不同：

互斥锁会将操作串行化，可以保证操作完全有序，适合资源只能由一个协程进行操作的情况，并发能力弱；
读写锁适合读多写少的情况，并发能有比较强。

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值是顺序增加的，而使用读写互斥锁，数据则是无序的。

2.基础知识

讲锁的具体实现原理之前，需要先复习几个基础知识：进程同步、信号量和自旋。

2.1进程同步

进程同步本质上是靠控制对临界区的访问权限实现的。

临界资源：把在一段时间内只允许一个进程访问的资源称为临界资源或独占资源。计算机系统中的大多数物理设备，以及某些软件中所用的栈、变量和表格，都属于临界资源，它们要求被互斥地共享
临界区：在每个进程中访问临界资源的那段代码称为临界区(critical section)。若能保证诸进程互斥地进入自己的临界区，便可实现诸进程对临界资源的互斥访问。

进入区(entry section)：如果此刻该临界资源未被访问，进程便可进入临界区对该资源进行访问，并设置它正被访问的标志；如果此刻该临界资源正被某进程访问，则本进程不能进入临界区。
退出区(exit section)：用于将临界区正被访问的标志恢复为未被访问的标志。

同步机制规则

(1) 空闲让进。当无进程处于临界区时，表明临界资源处于空闲状态，应允许一个请求进入临界区的进程立即进入自己的临界区，以有效地利用临界资源。

(2) 忙则等待。当已有进程进入临界区时，表明临界资源正在被访问，因而其它试图进入临界区的进程必须等待，以保证对临界资源的互斥访问。

(3) 有限等待。对要求访问临界资源的进程，应保证在有限时间内能进入自己的临界区，以免陷入“死等”状态。

(4) 让权等待。当进程不能进入自己的临界区时，应立即释放处理机，以免进程陷入“忙等”状态。

这个规则和现实一致：如果有空闲我就可以用吧（空闲让进）；如果不空闲，为了有序我可以等待（忙则等待）；我等待的时候没别的事情可以做，那可以去一边休息吧（让权等待）；你们不能让我老等着吧（有限等待）；

2.2信号量

1965 年，荷兰学者 Dijkstra 提出的信号量(Semaphores)机制是一种卓有成效的进程同步工具。Dijkstra，YYDS。

2.2.1类型

信号量现在已发展为如下四种类型：

整型信号量
记录型信号量
AND型信号量
信号量集

虽然信号量有不同类型，但核心是对：一个用于表示资源数目的整型量 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应用

利用信号量实现进程互斥为使多个进程能互斥地访问某临界资源，只须为该资源设置一互斥信号量 mutex，并设其初始值为 1，然后将各进程访问该资源的临界区(critical section)置于 wait(mutex)和 signal(mutex)操作之间即可。
利用信号量实现前驱关系设有两个并发执行的进程 P1 和 P2。P1 中有语句 S1；P2 中有语句 S2。我们希望在 S1 执行后再执行 S2。为实现这种前趋关系，我们只须使进程 P1 和 P2 共享一个公用信号量 S，并赋予其初值为 0，将 signal(S)操作放在语句 S1 后面；而在 S2 语句前面插入 wait(S)操作，即在进程 P1 中，用 S1；signal(S)；在进程 P2 中，用 wait(S)；S2；

2.3自旋

同步机制规则里有让权等待，自旋其实就是说在进程不能进入自己的临界区时是如何处理的。

2.3.1定义

加锁时，如果发现该锁当前由其他协程持有，尝试加锁的协程并不是马上转入阻塞，而是会持续的探测锁是否被释放，这个过程即为自旋过程。自旋时间很短，但如果在自旋过程中发现锁已被释放，那么协程可以立即获取锁。

2.3.2过程

自旋过程为先检查是否可以加锁，如果不可以，执行CPU PAUSE指令，CPU对该指令什么都不做，一般为30个时钟周期。PAUSE执行后，再检查是否可以加锁，循环往复。

在这个过程中，进程仍然是执行状态，不是睡眠状态。

2.3.3优势

自旋主要为了更加高效，减少损耗。自旋的优势是更充分的利用CPU，尽量避免协程切换。因为当前申请加锁的协程拥有CPU，如果经过短时间的自旋可以获得锁，当前协程可以继续运行，不必进入阻塞状态。

2.3.4条件

自旋不能随便使用，否则不但发挥不了优势，还会带来更多损耗，举个简单的例子：如果自旋次数不限制，而获得锁的进程很长时间后才释放锁，则自旋的进程这段时间CPU完全浪费了。

所以使用自旋，一定要满足一下条件：

自旋次数要足够小，通常为4，即自旋最多4次
CPU核数要大于1，否则自旋没有意义，因为此时不可能有其他协程释放锁
调度机制中的Process数量要大于1，否则自旋没有意义
调度机制中的可运行队列必须为空，否则会延迟协程调度，需要把CPU让给更需要的进程

2.3.5问题

自旋有个特性，无视正在排队等待加锁的进程，在自旋过程中，获取到锁便可加锁，类似于插队。

所以使用自旋会引发问题：极端情况下，很多进程正排队等待加锁，此时有进程刚到，开始自旋加锁，如果成功，该进程便插队成功加锁。如果此时不断有进程自旋加锁，则在排队的进程将长时间无法获取到锁。

一般解决方案为：锁添加饥饿状态，该状态下不允许自旋。

3.实现原理

3.1互斥锁Mutex

3.1.1 结构体

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表示互斥锁的状态，比如是否被锁定等。
sema表示信号量，协程阻塞等待该信号量，解锁的协程释放信号量从而唤醒等待信号量的协程。

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信号量，一旦持有锁的协程解锁，等待的协程会依次被唤醒。

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.

互斥量有两种模式：正常模式和饥饿模式。

正常模式：正常模式下等待的协程按照先入先出排列，当一个协程被唤醒后并不是直接拥有锁，该协程需要和刚刚到达的协程一起竞争锁的所有权。新到的协程有个优势，那就是它已经在CPU上运行了，而且新到的协程可能有很多，所以被唤醒的协程极有可能抢占不到锁。在这种情况下，被唤醒的协程会被放置于等待队列的队头。如果等待的协程超过1ms内没有获取到锁，将会把锁置为饥饿模式。

饥饿模式：在饥饿模式下，解锁的协程会将锁的所有权直接交给等待队列中位于队头的协程。正好解锁的那一刻有新的协程到达，新到达的协程也不会尝试自旋获取锁。相反，他们会将自己置于等待队列的队尾。

如果等待队列中的协程获取到锁，它会查看

(1)自己是否是等待队列中最后一个协程

(2)自己等待的时间是否小于1ms

如果有任意一个条件满足，将会将锁改为普通模式。

一般认为普通模式会有更好的性能，因为即使有等待的协程，新的协程可以连续获取到锁。饥饿模式能够防止等待协程长时间获取不到锁。

3.1.3 Lock

// 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))
   }
}

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.
// 加锁和解锁可以不是同一个协程
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)
   }
}

3.1.4 函数说明

【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。表示通过信号量解除当前协程阻塞。

3.1.5 流程图

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

Go互斥锁实现逻辑很复杂，能够看到大量的性能优化方面的代码，所以导致整个逻辑很难理解。大家即使看了注释和流程图，理解起来应该还是会有些困难。我的建议是，一是搞懂lock、woken、starving所代表的功能，二是不是要1.13版本的锁实现，可以看早期实现，会更加简单一些。

4.总结

本来以为写锁的实现会很快能完成，结果看这一两百行代码用了差不多一个星期。个人也不太建议看1.13锁的具体实现，太过于繁杂了。可以看一下https://www.cnblogs.com/niniwzw/p/3153955.html，讲了锁的演变。

更容易让大家理解的方式是使用状态机，将加锁和写锁操作都放入状态机中，但锁状态分四部分，加上各种操作，绘制起来比较耗时，如果大家有兴趣可以绘制一下。

写这篇文章的时候，有些资料查的大学教程《计算机操作系统》，发觉这些书真是好书，不但准确而且易懂，以前都是死记硬背，现在感觉简直是宝书。

读写锁另起一篇文章写吧，这篇已经太长了，写不动了。

资料

线程同步（互斥锁与信号量的作用与区别）
信号量及其使用和实现(超详细)
Go专家编程
Golang同步机制的实现
【我的架构师之路】- 说一说go中的sync包
Golang 互斥锁内部实现
go sync.Mutex 设计思想与演化过程（一）
一文读懂go中semaphore(信号量)源码
Go: 关于锁（mutex）的一些使用注意事项

在线咨询

上一篇：HTML5大文件上传技术
下一篇：Web前端最强JavaScript Excel处理插件-exceljs

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商

5个要点，避免踩坑小程序

一、小程序一键更新

二、小程序跳转类型

1. H5

2. 公众号文章

3. 小程序

三、推送微信服务通知

四、接入微信支付

1. 企业付款到零钱

2. 自动结算

3. 小程序与商户号绑定

五、通用注意点

六、小结

/ 感谢支持/

1.使用

2.基础知识

2.1进程同步

2.2信号量

2.2.1类型

2.2.2应用

2.3自旋

2.3.1定义

2.3.2过程

2.3.3优势

2.3.4条件

2.3.5问题

3.实现原理

3.1互斥锁Mutex

3.1.1 结构体

3.1.2 互斥公平

3.1.3 Lock

3.1.3 UnLock

3.1.4 函数说明

3.1.5 流程图

4.总结

资料

您的项目需求