Go 语言 channel 的阻塞问题

Python012

Go 语言 channel 的阻塞问题,第1张

Hello,大家好,又见面了!上一遍我们将 channel 相关基础以及使用场景。这一篇,还需要再次进阶理解channel 阻塞问题。以下创建一个chan类型为int,cap 为3。

channel 内部其实是一个环形buf数据结构 ,是一种滑动窗口机制,当make完后,就分配在 Heap 上。

上面,向 chan 发送一条“hello”数据:

如果 G1 发送数据超过指定cap时,会出现什么情况?

看下面实例:

以上会出现什么,chan 缓冲区允许大小为1,如果再往chan仍数据,满了就会被阻塞,那么是如何实现阻塞的呢?当 chan 满时,会进入 gopark,此时 G1 进入一个 waiting 状态,然后会创建一个 sudog 对象,其实就sendq队列,把 200放进去。等 buf 不满的时候,再唤醒放入buf里面。

通过如下源码,你会更加清晰:

上面,从 chan 获取数据:

Go 语言核心思想:“Do not communicate by sharing memoryinstead, share memory by communicating.” 你可以看看这本书名叫:Effective Go

如果接收者,接收一个空对象,也会发生什么情况?

代码示例

也会报错如下:

上面,从 chan 取出数据,可是没有数据了。此时,它会把 接收者 G2 阻塞掉,也是和G1发送者一样,也会执行 gopark 将状态改为 waiting,不一样的点就是。

正常情况下,接收者G2作为取出数据是去 buf 读取数据的,但现在,buf 为空了,此时,接收者G2会将sudog导出来,因为现在G2已经被阻塞了嘛,会把G2给G,然后将 t := <-ch 中变量t是在栈上的地址,放进去 elem ,也就是说,只存它的地址指针在sudog里面。

最后, ch <- 200当G1往 chan 添加200这个数据,正常情况是将数据添加到buf里面,然后唤醒 G2 是吧,而现在是将 G1 的添加200数据直接干到刚才G2阻塞的t这里变量里面。

你会认为,这样真的可以吗?想一想,G2 本来就是已经阻塞了,然后我们直接这么干肯定没有什么毛病,而且效率提高了,不需要再次放入buf再取出,这个过程也是需要时间。不然,不得往chan添加数据需要加锁、拷贝、解锁一序列操作,那肯定就慢了,我想Go语言是为了高效及内存使用率的考虑这样设计的。(注意,一般都是在runtime里面完成,不然会出现象安全问题。)

总结

chan 类型的特点:chan 如果为空,receiver 接收数据的时候就会阻塞等待,直到 chan 被关闭或者有新的数据到来。有这种个机制,就可以实现 wait/notify 的设计模式

相关面试题:

总体来说设计模式分为三大类:

一、创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

二、结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

三、行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1、工厂方法模式:

定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。

工厂模式有一个问题就是,类的创建依赖工厂类,也就是说,如果想要拓展程序,必须对工厂类进行修改,这违背了闭包原则,所以,从设计角度考虑,有一定的问题,这就用到工厂方法模式。

创建一个工厂接口和创建多个工厂实现类,这样一旦需要增加新的功能,直接增加新的工厂类就可以了,不需要修改之前的代码。

2、抽象工厂模式:

提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。抽象工厂需要创建一些列产品,着重点在于"创建哪些"产品上,也就是说,如果你开发,你的主要任务是划分不同差异的产品线,并且尽量保持每条产品线接口一致,从而可以从同一个抽象工厂继承。

3、单例模式:

单例对象(Singleton)是一种常用的设计模式。在Java应用中,单例对象能保证在一个JVM中,该对象只有一个实例存在。这样的模式有几个好处:

(1)某些类创建比较频繁,对于一些大型的对象,这是一笔很大的系统开销。

(2)省去了new操作符,降低了系统内存的使用频率,减轻GC压力。

(3)有些类如交易所的核心交易引擎,控制着交易流程,如果该类可以创建多个的话,系统完全乱了。(比如一个军队出现了多个司令员同时指挥,肯定会乱成一团),所以只有使用单例模式,才能保证核心交易服务器独立控制整个流程。

4、建造者模式:

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。

5、原型模式:

原型模式虽然是创建型的模式,但是与工程模式没有关系,从名字即可看出,该模式的思想就是将一个对象作为原型,对其进行复制、克隆,产生一个和原对象类似的新对象。本小结会通过对象的复制,进行讲解。在Java中,复制对象是通过clone()实现的,先创建一个原型类。

6、适配器模式:

适配器模式将某个类的接口转换成客户端期望的另一个接口表示,目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类:类的适配器模式、对象的适配器模式、接口的适配器模式。

7、装饰器模式:

顾名思义,装饰模式就是给一个对象增加一些新的功能,而且是动态的,要求装饰对象和被装饰对象实现同一个接口,装饰对象持有被装饰对象的实例。

8、代理模式:

代理模式就是多一个代理类出来,替原对象进行一些操作,比如我们在租房子的时候回去找中介,为什么呢?因为你对该地区房屋的信息掌握的不够全面,希望找一个更熟悉的人去帮你做,此处的代理就是这个意思。

9、外观模式:

外观模式是为了解决类与类之家的依赖关系的,像spring一样,可以将类和类之间的关系配置到配置文件中,而外观模式就是将他们的关系放在一个Facade类中,降低了类类之间的耦合度,该模式中没有涉及到接口。

10、桥接模式:

桥接模式就是把事物和其具体实现分开,使他们可以各自独立的变化。桥接的用意是:将抽象化与实现化解耦,使得二者可以独立变化,像我们常用的JDBC桥DriverManager一样。

JDBC进行连接数据库的时候,在各个数据库之间进行切换,基本不需要动太多的代码,甚至丝毫不用动,原因就是JDBC提供统一接口,每个数据库提供各自的实现,用一个叫做数据库驱动的程序来桥接就行了。

11、组合模式:

组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便。使用场景:将多个对象组合在一起进行操作,常用于表示树形结构中,例如二叉树,数等。

12、享元模式:

享元模式的主要目的是实现对象的共享,即共享池,当系统中对象多的时候可以减少内存的开销,通常与工厂模式一起使用。

13、策略模式:

策略模式定义了一系列算法,并将每个算法封装起来,使其可以相互替换,且算法的变化不会影响到使用算法的客户。需要设计一个接口,为一系列实现类提供统一的方法,多个实现类实现该接口,设计一个抽象类(可有可无,属于辅助类),提供辅助函数。

14、模板方法模式:

一个抽象类中,有一个主方法,再定义1...n个方法,可以是抽象的,也可以是实际的方法,定义一个类,继承该抽象类,重写抽象方法,通过调用抽象类,实现对子类的调用。

15、观察者模式:

观察者模式很好理解,类似于邮件订阅和RSS订阅,当我们浏览一些博客或wiki时,经常会看到RSS图标,就这的意思是,当你订阅了该文章,如果后续有更新,会及时通知你。

其实,简单来讲就一句话:当一个对象变化时,其它依赖该对象的对象都会收到通知,并且随着变化!对象之间是一种一对多的关系。

16、迭代子模式:

顾名思义,迭代器模式就是顺序访问聚集中的对象,一般来说,集合中非常常见,如果对集合类比较熟悉的话,理解本模式会十分轻松。这句话包含两层意思:一是需要遍历的对象,即聚集对象,二是迭代器对象,用于对聚集对象进行遍历访问。

17、责任链模式:

责任链模式,有多个对象,每个对象持有对下一个对象的引用,这样就会形成一条链,请求在这条链上传递,直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求,所以,责任链模式可以实现,在隐瞒客户端的情况下,对系统进行动态的调整。

18、命令模式:

命令模式的目的就是达到命令的发出者和执行者之间解耦,实现请求和执行分开。

19、备忘录模式:

主要目的是保存一个对象的某个状态,以便在适当的时候恢复对象,个人觉得叫备份模式更形象些,通俗的讲下:假设有原始类A,A中有各种属性,A可以决定需要备份的属性,备忘录类B是用来存储A的一些内部状态,类C呢,就是一个用来存储备忘录的,且只能存储,不能修改等操作。

20、状态模式:

状态模式在日常开发中用的挺多的,尤其是做网站的时候,我们有时希望根据对象的某一属性,区别开他们的一些功能,比如说简单的权限控制等。

21、访问者模式:

访问者模式把数据结构和作用于结构上的操作解耦合,使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。

若系统数据结构对象易于变化,经常有新的数据对象增加进来,则不适合使用访问者模式。访问者模式的优点是增加操作很容易,因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中,其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。

22、中介者模式:

中介者模式也是用来降低类类之间的耦合的,因为如果类类之间有依赖关系的话,不利于功能的拓展和维护,因为只要修改一个对象,其它关联的对象都得进行修改。

如果使用中介者模式,只需关心和Mediator类的关系,具体类类之间的关系及调度交给Mediator就行,这有点像spring容器的作用。

23、解释器模式:

解释器模式一般主要应用在OOP开发中的编译器的开发中,所以适用面比较窄。

扩展资料:

介绍三本关于设计模式的书:

1、《设计模式:可复用面向对象软件的基础》

作者:[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社: 机械工业出版社

2、《软件秘笈:设计模式那点事》

作者:郑阿奇

出版社:电子工业出版社

3、《设计模式:基于C#的工程化实现及扩展》

作者:王翔

出版社:电子工业出版社

参考资料来源:百度百科-设计模式

23个设计模式:

根据目的设计模式可以分为创造模式,结构模式和行为模式,创建模式用于处理对象的创建。结构模式用于处理类或对象的组合。

行为模式用于描述类或对象如何交互以及如何分配职责,创建模式用于处理对象的创建。主要包括以下五种设计模式:

工厂方法模式()

抽象工厂模式(AbstractFactoryPattern)

建造者模式(BuilderPattern)

原型模式(PrototypePattern)

单例模式(SingletonPattern)

结构模式用于处理类或对象的组合,包括以下七个设计模式:

适配器模式(AdapterPattern)

桥接模式(BridgePattern)

组合模式(CompositePattern)

装饰者模式(DecoratorPattern)

外观模式(FacadePattern)

享元模式(FlyweightPattern)

代理模式(ProxyPattern)

行为模式描述类或对象如何交互以及它们如何分配职责。它由以下11种设计模式组成:

责任链模式(Chain的ResponsibilityPattern)

命令模式(CommandPattern)

解释器模式(InterpreterPattern)

迭代器模式(IteratorPattern)

中介者模式(MediatorPattern)

备忘录模式(MementoPattern)

观察者模式(ObserverPattern)

状态模式(StatePattern)

策略模式(StrategyPattern)

模板方法模式(TemplateMethodPattern)

访问者模式(VisitorPattern)

单例模式实现1:

公共类Singleton{

类共享实例对象

私有静态单例;单例=零;

//私有构造函数

私有Singleton(){

系统。出去了。这是单例!!);

//获取单例方法

公共同步静态单例getInstance(){

//确定共享对象是否为空,如何空一个新对象

If(singleton==null){

singleton=newsingleton();

返回单例。

单例模式实现2:

公共类Singleton{

类共享实例对象实例化

PrivatestaticSingletonSingleton=newSingleton();

//私有构造函数

私有Singleton(){

系统:出去了,这是单例!!);

//获取单例方法

公共静态单例getInstance(){

直接返回共享对象

返回单例。

扩展资料:

注意事项:

设计模式主要分三个类型:创建型和行为型。

Singleton:确保一个类只有一个实例,并为其提供一个全局访问点

AbstractFactory:提供一个接口,用于创建一系列相关或相互依赖的对象,而无需指定它们的具体类。

FactoryMethod:定义一个用于创建对象的接口,并让子类决定实例化哪个类。工厂方法将类的实例化延迟到子类。

Builder:将复杂对象的构造与其表示分离,使相同的构造过程可以创建不同的表示。

Prototype:指定要使用Prototype实例创建的对象的类型,并复制该原型来创建一个新对象。

Composite:将对象组合成树状结构,以表示整体各部分之间的关系。组合使用户一致地使用单个对象和组合对象。

Facade:为子系统fa中的一组接口提供一致的接口。Ade提供了一个高级接口,使子系统更易于使用。

Proxy:为其他对象提供一个代理,以控制对该对象的访问

Adapter:将一个接口类转换为客户想要的另一个接口类。适配器模式使那些由于接口不兼容而无法一起工作的类一起工作。

Decrator:式比子类化更灵活,可以为对象动态添加一些额外的职责。

Bridge:模式将抽象部分与其实现部分分离,以便它们可以独立地更改。

Flyweight:享元模式