ST灬Lee

ST灬Lee 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 个人简介什么都没有

个人动态

ST灬Lee 收藏了文章 · 2019-06-17

推荐一些PHP及后端相关的技术博客

ST灬Lee 收藏了文章 · 2019-02-16

Go goroutine理解

Go语言最大的特色就是从语言层面支持并发(Goroutine),Goroutine是Go中最基本的执行单元。事实上每一个Go程序至少有一个Goroutine:主Goroutine。当程序启动时,它会自动创建。

为了更好理解Goroutine,现讲一下线程和协程的概念

线程(Thread):有时被称为轻量级进程(Lightweight Process,LWP),是程序执行流的最小单元。一个标准的线程由线程ID,当前指令指针(PC),寄存器集合和堆栈组成。另外,线程是进程中的一个实体,是被系统独立调度和分派的基本单位,线程自己不拥有系统资源,只拥有一点儿在运行中必不可少的资源,但它可与同属一个进程的其它线程共享进程所拥有的全部资源。

线程拥有自己独立的栈和共享的堆,共享堆,不共享栈,线程的切换一般也由操作系统调度。

协程(coroutine):又称微线程与子例程(或者称为函数)一样,协程(coroutine)也是一种程序组件。相对子例程而言,协程更为一般和灵活,但在实践中使用没有子例程那样广泛。

和线程类似,共享堆,不共享栈,协程的切换一般由程序员在代码中显式控制。它避免了上下文切换的额外耗费,兼顾了多线程的优点,简化了高并发程序的复杂。

Goroutine和其他语言的协程(coroutine)在使用方式上类似,但从字面意义上来看不同(一个是Goroutine,一个是coroutine),再就是协程是一种协作任务控制机制,在最简单的意义上,协程不是并发的,而Goroutine支持并发的。因此Goroutine可以理解为一种Go语言的协程。同时它可以运行在一个或多个线程上。

先给个简单实例

func loop() {
    for i := 0; i < ; i++ {
        fmt.Printf("%d ", i)
    }
}

func main() {
   go loop() // 启动一个goroutine
    loop()
}

GO并发的实现原理

一、Go并发模型

Go实现了两种并发形式。第一种是大家普遍认知的:多线程共享内存。其实就是Java或者C++等语言中的多线程开发。另外一种是Go语言特有的,也是Go语言推荐的:CSP(communicating sequential processes)并发模型。

CSP并发模型是在1970年左右提出的概念,属于比较新的概念,不同于传统的多线程通过共享内存来通信,CSP讲究的是“以通信的方式来共享内存”。

请记住下面这句话:
DO NOT COMMUNICATE BY SHARING MEMORY; INSTEAD, SHARE MEMORY BY COMMUNICATING.
“不要以共享内存的方式来通信,相反,要通过通信来共享内存。”

普通的线程并发模型,就是像Java、C++、或者Python,他们线程间通信都是通过共享内存的方式来进行的。非常典型的方式就是,在访问共享数据(例如数组、Map、或者某个结构体或对象)的时候,通过锁来访问,因此,在很多时候,衍生出一种方便操作的数据结构,叫做“线程安全的数据结构”。例如Java提供的包”java.util.concurrent”中的数据结构。Go中也实现了传统的线程并发模型。

Go的CSP并发模型,是通过goroutinechannel来实现的。

  • goroutine 是Go语言中并发的执行单位。有点抽象,其实就是和传统概念上的”线程“类似,可以理解为”线程“。
  • channel是Go语言中各个并发结构体(goroutine)之前的通信机制。 通俗的讲,就是各个goroutine之间通信的”管道“,有点类似于Linux中的管道。

生成一个goroutine的方式非常的简单:Go一下,就生成了。

go f();

通信机制channel也很方便,传数据用channel <- data,取数据用<-channel

在通信过程中,传数据channel <- data和取数据<-channel必然会成对出现,因为这边传,那边取,两个goroutine之间才会实现通信。

而且不管传还是取,必阻塞,直到另外的goroutine传或者取为止。

示例如下:

package main

import "fmt"

func main() {
   
   messages := make(chan string)

   go func() { messages <- "ping" }()

   msg := <-messages
   fmt.Println(msg)
}

注意 main()本身也是运行了一个goroutine。

messages:= make(chan int) 这样就声明了一个阻塞式的无缓冲的通道

chan 是关键字 代表我要创建一个通道

GO并发模型的实现原理

我们先从线程讲起,无论语言层面何种并发模型,到了操作系统层面,一定是以线程的形态存在的。而操作系统根据资源访问权限的不同,体系架构可分为用户空间和内核空间;内核空间主要操作访问CPU资源、I/O资源、内存资源等硬件资源,为上层应用程序提供最基本的基础资源,用户空间呢就是上层应用程序的固定活动空间,用户空间不可以直接访问资源,必须通过“系统调用”、“库函数”或“Shell脚本”来调用内核空间提供的资源。

我们现在的计算机语言,可以狭义的认为是一种“软件”,它们中所谓的“线程”,往往是用户态的线程,和操作系统本身内核态的线程(简称KSE),还是有区别的。

线程模型的实现,可以分为以下几种方式:

用户级线程模型

如图所示,多个用户态的线程对应着一个内核线程,程序线程的创建、终止、切换或者同步等线程工作必须自身来完成。它可以做快速的上下文切换。缺点是不能有效利用多核CPU。

内核级线程模型

这种模型直接调用操作系统的内核线程,所有线程的创建、终止、切换、同步等操作,都由内核来完成。一个用户态的线程对应一个系统线程,它可以利用多核机制,但上下文切换需要消耗额外的资源。C++就是这种。

两级线程模型

这种模型是介于用户级线程模型和内核级线程模型之间的一种线程模型。这种模型的实现非常复杂,和内核级线程模型类似,一个进程中可以对应多个内核级线程,但是进程中的线程不和内核线程一一对应;这种线程模型会先创建多个内核级线程,然后用自身的用户级线程去对应创建的多个内核级线程,自身的用户级线程需要本身程序去调度,内核级的线程交给操作系统内核去调度。

M个用户线程对应N个系统线程,缺点增加了调度器的实现难度。

Go语言的线程模型就是一种特殊的两级线程模型(GPM调度模型)。

Go线程实现模型MPG

M指的是Machine,一个M直接关联了一个内核线程。由操作系统管理。
P指的是”processor”,代表了M所需的上下文环境,也是处理用户级代码逻辑的处理器。它负责衔接M和G的调度上下文,将等待执行的G与M对接。
G指的是Goroutine,其实本质上也是一种轻量级的线程。包括了调用栈,重要的调度信息,例如channel等。

P的数量由环境变量中的GOMAXPROCS决定,通常来说它是和核心数对应,例如在4Core的服务器上回启动4个线程。G会有很多个,每个P会将Goroutine从一个就绪的队列中做Pop操作,为了减小锁的竞争,通常情况下每个P会负责一个队列。

三者关系如下图所示:

以上这个图讲的是两个线程(内核线程)的情况。一个M会对应一个内核线程,一个M也会连接一个上下文P,一个上下文P相当于一个“处理器”,一个上下文连接一个或者多个Goroutine。为了运行goroutine,线程必须保存上下文。

上下文P(Processor)的数量在启动时设置为GOMAXPROCS环境变量的值或通过运行时函数GOMAXPROCS()。通常情况下,在程序执行期间不会更改。上下文数量固定意味着只有固定数量的线程在任何时候运行Go代码。我们可以使用它来调整Go进程到个人计算机的调用,例如4核PC在4个线程上运行Go代码。

图中P正在执行的Goroutine为蓝色的;处于待执行状态的Goroutine为灰色的,灰色的Goroutine形成了一个队列runqueues

Go语言里,启动一个goroutine很容易:go function 就行,所以每有一个go语句被执行,runqueue队列就在其末尾加入一个goroutine,一旦上下文运行goroutine直到调度点,它会从其runqueue中弹出goroutine,设置堆栈和指令指针并开始运行goroutine。

抛弃P(Processor)

你可能会想,为什么一定需要一个上下文,我们能不能直接除去上下文,让Goroutinerunqueues挂到M上呢?答案是不行,需要上下文的目的,是让我们可以直接放开其他线程,当遇到内核线程阻塞的时候。

一个很简单的例子就是系统调用sysall,一个线程肯定不能同时执行代码和系统调用被阻塞,这个时候,此线程M需要放弃当前的上下文环境P,以便可以让其他的Goroutine被调度执行。

如上图左图所示,M0中的G0执行了syscall,然后就创建了一个M1(也有可能来自线程缓存),(转向右图)然后M0丢弃了P,等待syscall的返回值,M1接受了P,将·继续执行Goroutine队列中的其他Goroutine

当系统调用syscall结束后,M0会“偷”一个上下文,如果不成功,M0就把它的Gouroutine G0放到一个全局的runqueue中,将自己置于线程缓存中并进入休眠状态。全局runqueue是各个P在运行完自己的本地的Goroutine runqueue后用来拉取新goroutine的地方。P也会周期性的检查这个全局runqueue上的goroutine,否则,全局runqueue上的goroutines可能得不到执行而饿死。

均衡的分配工作

按照以上的说法,上下文P会定期的检查全局的goroutine 队列中的goroutine,以便自己在消费掉自身Goroutine队列的时候有事可做。假如全局goroutine队列中的goroutine也没了呢?就从其他运行的中的P的runqueue里偷。

每个P中的Goroutine不同导致他们运行的效率和时间也不同,在一个有很多P和M的环境中,不能让一个P跑完自身的Goroutine就没事可做了,因为或许其他的P有很长的goroutine队列要跑,得需要均衡。
该如何解决呢?

Go的做法倒也直接,从其他P中偷一半!

Goroutine 小结

优点:

1、开销小

POSIX的thread API虽然能够提供丰富的API,例如配置自己的CPU亲和性,申请资源等等,线程在得到了很多与进程相同的控制权的同时,开销也非常的大,在Goroutine中则不需这些额外的开销,所以一个Golang的程序中可以支持10w级别的Goroutine。

每个 goroutine (协程) 默认占用内存远比 Java 、C 的线程少(goroutine:2KB ,线程:8MB)

2、调度性能好

在Golang的程序中,操作系统级别的线程调度,通常不会做出合适的调度决策。例如在GC时,内存必须要达到一个一致的状态。在Goroutine机制里,Golang可以控制Goroutine的调度,从而在一个合适的时间进行GC。

在应用层模拟的线程,它避免了上下文切换的额外耗费,兼顾了多线程的优点。简化了高并发程序的复杂度。

缺点:

协程调度机制无法实现公平调度。

参考:

links

查看原文

ST灬Lee 关注了专栏 · 2019-01-21

Swoole

PHP的协程框架

关注 7100

ST灬Lee 赞了文章 · 2019-01-21

Swoole 2019 :化繁为简、破茧成蝶

Swoole开源项目从2012年开始发布第一个版本,到现在已经有近7年的历史。在这七年的时间里:

  • 提交了8821次代码变更
  • 发布了287个版本
  • 收到并解决1161issue反馈
  • 合并了603pull request
  • 共有100位开发者贡献代码
  • GitHub收获了11940颗星

贡献者

协程

2018年我们推出了全新的Swoole4版本,在此之前Swoole主要的编程方式还是同步阻塞模式或异步回调。新的基于协程实现的CSP编程逐渐成为我们唯一推荐使用的编程模式。协程将纷繁复杂异步编程大大简化。使用Swoole4协程,既简单又强大。在未来的Swoole5版本,我们计划删除非协程的相关特性和代码,减少历史包袱,提升稳定性,降低复杂度,减少不必要的选项,纯粹协程化。

过去6年我们的团队主要以兼职开发为主,团队成员大多来自于腾讯、阿里、滴滴、百度、360、小米等国内一线互联网企业,还有一部分是国外的PHP开发者,甚至PHP语言ZendVM内核作者Dmitry Stogov也曾向Swoole贡献了代码。除此之外,我们还招募了一些在校大学生为Swoole编写代码,逐步培养年轻一代开发者。

20187月份我们组建了全职开发团队,专注于Swoole内核以及Swoole Cloud云原生组件和生态链的开发。告别过去的草莽班子,转变为专业化的开源技术研发团队。

我们的目标是让Swoole项目成为Node.jsGo这样的工业级技术,成为PHP编程语言的在异步IO和网络通信方面的基石。

研发管理

成立全职研发团队后,我们逐渐建立了非常完善的研发管理体系,提升Swoole的软件质量。主要包括以下几个方面:

测试驱动(TDD)

现在我们投入大量精力实现单元测试脚本、压测脚本、自动化测试,提升单元测试覆盖率。目前已有680项测试用例,17项压测项目,在Travis-CI平台可以看到每一次CommitPull Request的编译、测试结果。

研发工作也基于TDD进行,在开发新特性、重构、Bug Fix时,会先编写对应的单元测试脚本,测试覆盖到代码变更的所有场景。

单元测试

代码审查(Code Review)

团队成员之间进行代码交叉审查、互相Code Review,对于代码变更的细节进行充分的评估和讨论。

重大变更,会进行团队Review,花费数小时甚至数天讨论每一行代码变更细节。

RFC 机制

对于非Bug Fix、非性能提升、非重构,新特性或有可能改变底层行为的变更,我们会分为4个步骤进行。

  1. 发起RFC的提案,https://github.com/swoole/rfc...,提案内容会详细阐述此项变更的前因后果、相关配置项、影响的范围、使用方法、示例。
  2. 提案讨论,我们会对提案进行充分的讨论,刨根问底,分析优劣,推敲细节。所有问题均讨论清楚后,最终立项,开始实现。
  3. 开发负责人创建git分支,编写单元测试脚本,编写代码,实现提案中的所有内容,最终发起Pull Request
  4. 交叉评审,检查代码,提出改进意见,反馈给开发负责人,继续完善细节。最终合并到主干。

整个过程均是在GitHub平台公开进行的,对Swoole项目感兴趣的PHPer均可参与。

Swoole RFC

灰度测试

为了保证正式版本的稳定性,我们在发布前会在内部项目上进行灰度测试,检验新版本的稳定性。

另外我们与大部分Swoole框架作者建立了联系,新版本会先发给各大框架的作者提前试用。有重大底层变更、或不兼容项会提前与其他Swoole之上的开源项目作者进行沟通。

总结

在过去的几年,Swoole项目做的并不是很专业,存在较多BUG和难用的地方,也让很多使用者踩到了不少坑。最近半年成立全职研发团队后,我们在研发管理方面进步飞快,Swoole的稳定性、成熟度方面已今非昔比。稳定性始终是第一位的,我们在未来将会更加谨慎、严谨,保证质量。

重构

2018年下半年我们对底层的代码进行了多次重构,在代码结构、可读性、复用性、封装度方面进行了很多优化。使得Swoole软件更为简洁、优雅。

编程语言方面,我们现在逐渐使用C++替代C语言。C++提供的面向对象、智能指针、容器、模板等特性能够帮助我们进一步提升团队的开发效率。

在此也欢迎各位PHPer参与Swoole项目,贡献代码。

文档

Swoole的文档也是广为开发者诟病的一个方面。在2018年我们团队在文档方面逐渐加大投入。重新编写梳理文档,加入丰富的例子程序,加入更详细的配图,修复细节问题,删除带有感情色彩的语句,更加客观中立严谨。

2019 未来

新的一年我们主要有3个方向上发力。

做减法

删除非协程的特性,删除不必要的模块,减少历史包袱,提升稳定性、降低复杂度,减少不必要的选项,化繁为简,更简单。

Swoole内核层面仍然会继续不断重构、精简,减少代码行数,清理冗余代码,尽可能地实现代码复用。

深入项目

2018年底,我们已经开始逐渐与在生产环境上大量使用Swoole的企业建立联系,包括腾讯云阅文好未来陌陌优信等企业。了解实际应用场景、业务模式,进行深度交流合作,提供建议,帮助企业技术团队更好的解决业务问题,接受反馈改进底层。

生态链

2019年我们会基于Swoole4协程开发一些配套的工具和组件,弥补PHPCloud Native时代生态链方面的不足。

查看原文

赞 272 收藏 49 评论 80

ST灬Lee 回答了问题 · 2017-07-18

PHP每半小时执行一次怎么写?

写个脚本,用crontab定时以php-cli模式运行.

关注 17 回答 13

ST灬Lee 回答了问题 · 2017-02-28

解决laravel只能访问欢迎页面,别的页面都报404错误

laravel的web根目录在public下

关注 8 回答 7

ST灬Lee 关注了问题 · 2017-01-01

解决微信开发如何前后端完全分离?

我今天试了一下用vue和php开发微信公众号,在vue通过ajax向后台获取用户信息的时候,需要回调到微信的oauth,所以返回了302请求,得不到数据。有没有好的解决方案?

关注 5 回答 1

ST灬Lee 关注了问题 · 2016-12-21

解决求推荐,做WEB API用哪个PHP框架比较好?

老问题了,不过现在技术发展的快希望听听大家有没有新鲜好用的框架。

需求:

RESTful;
轻量级;
有较多的插件、模块支持。

我只用它做接口,所以什么网页模板之类的功能不需要,没有最好。谢谢~

关注 11 回答 10

认证与成就

  • 获得 4 次点赞
  • 获得 15 枚徽章 获得 0 枚金徽章, 获得 5 枚银徽章, 获得 10 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2015-08-19
个人主页被 219 人浏览