设计模式总结:

前言：个人觉得设计模式就是各个对象在不同的时机、不同的调用方被创建，组合结构和封装的侧重点有些不同，从而形成了各个模式的概念。

简单工厂模式

通过在工厂类中进行判断，然后创建需要的功能类。
简单工厂模式是工厂模式中最简单的一种，他可以用比较简单的方式隐藏创建对象的细节，一般只需要告诉工厂类所需要的类型，工厂类就会返回需要的产品类，但客户端看到的只是产品的抽象对象，无需关心到底是返回了哪个子类。客户端唯一需要知道的具体子类就是工厂子类。除了这点，基本是达到了依赖倒转原则的要求。

假如，我们不用工厂类，只用AbstractProduct和它的子类，那客户端每次使用不同的子类的时候都需要知道到底是用哪一个子类，当类比较少的时候还没什么问题，但是当类比较多的时候，管理起来就非常的麻烦了，就必须要做大量的替换，一个不小心就会发生错误。

而使用了工厂类之后，就不会有这样的问题，不管里面多少个类，我只需要知道类型号即可。不过，这里还有一个疑问，那就是如果我每次用工厂类创建的类型都不相同，这样修改起来的时候还是会出现问题，还是需要大量的替换。所以简单工厂模式一般应该于程序中大部分地方都只使用其中一种产品，工厂类也不用频繁创建产品类的情况。这样修改的时候只需要修改有限的几个地方即可。

客户只需要知道SimpleFactory就可以了，使用的时候也是使用的AbstractFactory，这样客户端只在第一次创建工厂的时候是知道具体的细节的，其他时候它都只知道AbstractFactory，这样就完美的达到了依赖倒转的原则。

常用的场景：
例如部署多种数据库的情况，可能在不同的地方要使用不同的数据库，此时只需要在配置文件中设定数据库的类型，每次再根据类型生成实例，这样，不管下面的数据库类型怎么变化，在客户端看来都是只有一个AbstractProduct，使用的时候根本无需修改代码。提供的类型也可以用比较便于识别的字符串，这样不用记很长的类名，还可以保存为配置文件。这样，每次只需要修改配置文件和添加新的产品子类即可。所以简单工厂模式一般应用于多种同类型类的情况，将这些类隐藏起来，再提供统一的接口，便于维护和修改。

优点

1. 隐藏了对象创建的细节，将产品的实例化推迟到子类中实现。
2. 客户端基本不用关心使用的是哪个产品，只需要知道用哪个工厂就行了，提供的类型也可以用比较便于识别的字符串。
3. 方便添加新的产品子类，每次只需要修改工厂类传递的类型值就行了。
4. 遵循了依赖倒转原则。

缺点

1. 要求产品子类的类型差不多，使用的方法名都相同，如果类比较多，而所有的类又必须要添加一种方法，则会是非常麻烦的事情。或者是一种类另一种类有几种方法不相同，客户端无法知道是哪一个产品子类，也就无法调用这几个不相同的方法。
2. 每添加一个产品子类，都必须在工厂类中添加一个判断分支，这违背了开放-封闭原则。

代码演示：
抽象产品类代码：

1
2
3
4
5
6
7
8
9
10

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    /// 抽象产品类： 汽车
    /// </summary>
    public interface ICar
    {
        void GetCar();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

namespace CNBlogs.DesignPattern.Common
{
    public enum CarType
    {
        SportCarType = 0,
        JeepCarType = 1,
        HatchbackCarType = 2
    }

    /// <summary>
    /// 具体产品类： 跑车
    /// </summary>
    public class SportCar : ICar
    {
        public void GetCar()
        {
            Console.WriteLine("场务把跑车交给范·迪塞尔");
        }
    }

    /// <summary>
    /// 具体产品类： 越野车
    /// </summary>
    public class JeepCar : ICar
    {
        public void GetCar()
        {
            Console.WriteLine("场务把越野车交给范·迪塞尔");
        }
    }

    /// <summary>
    /// 具体产品类： 两箱车
    /// </summary>
    public class HatchbackCar : ICar
    {
        public void GetCar()
        {
            Console.WriteLine("场务把两箱车交给范·迪塞尔");
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

namespace CNBlogs.DesignPattern.Common
{
    public class Factory
    {
        public ICar GetCar(CarType carType)
        {
            switch (carType)
            {
                case CarType.SportCarType:
                    return new SportCar();
                case CarType.JeepCarType:
                    return new JeepCar();
                case CarType.HatchbackCarType:
                    return new HatchbackCar();
                default:
                    throw new Exception("爱上一匹野马,可我的家里没有草原. 你走吧！");
            }
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

//------------------------------------------------------------------------------
// <copyright file="Program.cs" company="CNBlogs Corporation">
//     Copyright (C) 2015-2016 All Rights Reserved
//     原博文地址： http://www.cnblogs.com/toutou/
//     作      者: 请叫我头头哥
// </copyright> 
//------------------------------------------------------------------------------
namespace CNBlogs.DesignPattern
{
    using System;
    using CNBlogs.DesignPattern.Common;

    class Program
    {
        static void Main(string[] args)
        {
            ICar car;
            try
            {
                Factory factory = new Factory();

                Console.WriteLine("范·迪塞尔下一场戏开跑车。");
                car = factory.GetCar(CarType.SportCarType);
                car.GetCar();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
    }
}

策略模式

假设一个功能类是一个策略，调用的时候需要创建这个策略的实例，传进一个类似策略控制中心的方法中，然后通过策略基类调用这个传进去的实例子类的方法。

优点：就是相对工厂模式免去了创建那个功能类的判断，简化了工厂模式。缺点：就是把子类实例赋值给了父类，这样就丢掉了子类新增的功能。

工厂方法模式(属于工厂模式)

把简单工厂模式中的工厂类，做了进一步的抽象为接口或抽象类，给各个功能创建一个对应的工厂类，然后在这个工厂类里面去创建对应的实例。
工厂模式基本与简单工厂模式差不多，上面也说了，每次添加一个产品子类都必须在工厂类中添加一个判断分支，这样违背了开放-封闭原则，因此，工厂模式就是为了解决这个问题而产生的。

既然每次都要判断，那我就把这些判断都生成一个工厂子类，这样，每次添加产品子类的时候，只需再添加一个工厂子类就可以了。这样就完美的遵循了开放-封闭原则。但这其实也有问题，如果产品数量足够多，要维护的量就会增加，好在一般工厂子类只用来生成产品类，只要产品子类的名称不发生变化，那么基本工厂子类就不需要修改，每次只需要修改产品子类就可以了。

同样工厂模式一般应该于程序中大部分地方都只使用其中一种产品，工厂类也不用频繁创建产品类的情况。这样修改的时候只需要修改有限的几个地方即可。

常用的场景
基本与简单工厂模式一致，只不过是改进了简单工厂模式中的开放-封闭原则的缺陷，使得模式更具有弹性。将实例化的过程推迟到子类中，由子类来决定实例化哪个。

优点：基本与简单工厂模式一致，多的一点优点就是遵循了开放-封闭原则，使得模式的灵活性更强。
缺点：当新增一个功能类，就需要创建对于的工厂类，相比简单工厂模式，免去了判断创建那个具体实例，但会创建过多的类，还不如策略模式。

代码演示：

抽象工厂代码：

1
2
3
4
5
6
7

namespace CNBlogs.DesignPattern.Common
{
    public interface IFactory
    {
        ICar CreateCar();
    }
}

1
2
3
4
5
6
7

namespace CNBlogs.DesignPattern.Common
{
    public interface ICar
    {
        void GetCar();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    ///  具体工厂类： 用于创建跑车类
    /// </summary>
    public class SportFactory : IFactory
    {
        public ICar CreateCar()
        {
            return new SportCar();
        }
    }

    /// <summary>
    ///  具体工厂类： 用于创建越野车类
    /// </summary>
    public class JeepFactory : IFactory
    {
        public ICar CreateCar()
        {
            return new JeepCar();
        }
    }

    /// <summary>
    ///  具体工厂类： 用于创建两厢车类
    /// </summary>
    public class HatchbackFactory : IFactory
    {
        public ICar CreateCar()
        {
            return new HatchbackCar();
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    /// 具体产品类： 跑车
    /// </summary>
    public class SportCar : ICar
    {
        public void GetCar()
        {
            Console.WriteLine("场务把跑车交给范·迪塞尔");
        }
    }

    /// <summary>
    /// 具体产品类： 越野车
    /// </summary>
    public class JeepCar : ICar
    {
        public void GetCar()
        {
            Console.WriteLine("场务把越野车交给范·迪塞尔");
        }
    }

    /// <summary>
    /// 具体产品类： 两箱车
    /// </summary>
    public class HatchbackCar : ICar
    {
        public void GetCar()
        {
            Console.WriteLine("场务把两箱车交给范·迪塞尔");
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

//------------------------------------------------------------------------------
// <copyright file="Program.cs" company="CNBlogs Corporation">
//     Copyright (C) 2015-2016 All Rights Reserved
//     原博文地址： http://www.cnblogs.com/toutou/
//     作      者: 请叫我头头哥
// </copyright> 
//------------------------------------------------------------------------------
namespace CNBlogs.DesignPattern
{
    using System.IO;
    using System.Configuration;
    using System.Reflection;
    using CNBlogs.DesignPattern.Common;

    class Program
    {
        static void Main(string[] args)
        {
            // 工厂类的类名写在配置文件中可以方便以后修改
            string factoryType = ConfigurationManager.AppSettings["FactoryType"];

            // 这里把DLL配置在数据库是因为以后数据可能发生改变
            // 比如说现在的数据是从sql server取的，以后需要从oracle取的话只需要添加一个访问oracle数据库的工程就行了
            string dllName = ConfigurationManager.AppSettings["DllName"];

            // 利用.NET提供的反射可以根据类名来创建它的实例，非常方便
            var currentAssembly = System.Reflection.Assembly.GetExecutingAssembly();
            string codeBase = currentAssembly.CodeBase.ToLower().Replace(currentAssembly.ManifestModule.Name.ToLower(), string.Empty);
            IFactory factory = Assembly.LoadFrom(Path.Combine(codeBase, dllName)).CreateInstance(factoryType) as IFactory;
            ICar car = factory.CreateCar();
            car.GetCar();
        }
    }
}

装饰模式

一般情况下，当一个基类写好之后，我们也许不愿意去改动，也不能改动，原因是
这样的在项目中用得比较久的基类，一旦改动，也许会影响其他功能模块，但是，
又要在该类上面添加功能。使用继承，当在A阶段，写出继承类，用过一段时间，发
现又要添加新功能，于是又要从原始类或A阶段的类继承，周而复始，慢慢的，子类就越来越多，层级就越来越深。然而，事实上，在C阶段需要A阶段的功能，但不需要B阶段的功能，在这种复杂情形下，继承就显得不灵活，于是想到了装饰模式。
装饰模式：
需要扩展一个类的功能，或给一个类增加附加责任
需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。

在使用装饰模式前，需要了解虚方法和抽象方法的区别：虚方法，是实例方法，可以在子类中覆盖，也可以由该类对象直接调用。抽象方法需要写在抽象类中，抽象类不能实例化，所以要使用抽象方法必须由子类实现后方可调用。

该模式中，要被扩展的类可以是包含抽象方法的抽象类，也可以是包含虚方法的实例类，也可以是普通实例类。装饰模式就是在原有基类上做扩展，至于基类是什么性质并不重要.

装饰模式在C#代码，和扩展方法，惊人的类似。

• Component为统一接口，也是装饰类和被装饰类的基本类型。
• ConcreteComponent为具体实现类，也是被装饰类，他本身是个具有一些功能的完整的类。
• Decorator是装饰类，实现了Component接口的同时还在内部维护了一个ConcreteComponent的实例，并可以通过构造函数初始化。而Decorator本身，- 通常采用默认实现，他的存在仅仅是一个声明：我要生产出一些用于装饰的子类了。而其子类才是赋有具体装饰效果的装饰产品类。
• ConcreteDecorator是具体的装饰产品类，每一种装饰产品都具有特定的装饰效果。可以通过构造器声明装饰哪种类型的ConcreteComponent，从而对其进行装饰。

最简单的代码实现装饰器模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

//基础接口
public interface Component {
    
    public void biu();
}
//具体实现类
public class ConcretComponent implements Component {

    public void biu() {
        
        System.out.println("biubiubiu");
    }
}
//装饰类
public class Decorator implements Component {

    public Component component;
    
    public Decorator(Component component) {
        
        this.component = component;
    }
    
    public void biu() {
        
        this.component.biu();
    }
}
//具体装饰类
public class ConcreteDecorator extends Decorator {

    public ConcreteDecorator(Component component) {

        super(component);
    }

    public void biu() {
        
        System.out.println("ready?go!");
        this.component.biu();
    }
}

这样一个基本的装饰器体系就出来了，当我们想让Component在打印之前都有一个ready？go！的提示时，就可以使用ConcreteDecorator类了。具体方式如下：

1
2
3
4
5
6
7

　　//使用装饰器
　　Component component = new ConcreteDecorator(new ConcretComponent());
　　component.biu();

　　//console：
　　ready?go!
　　biubiubiu

为何使用装饰器模式？
一个设计模式的出现一定有他特殊的价值。仅仅看见上面的结构图你可能会想，为何要兜这么一圈来实现？仅仅是想要多一行输出，我直接继承ConcretComponent，或者直接在另一个Component的实现类中实现不是一样吗？

首先，装饰器的价值在于装饰，他并不影响被装饰类本身的核心功能。在一个继承的体系中，子类通常是互斥的。比如一辆车，品牌只能要么是奥迪、要么是宝马，不可能同时属于奥迪和宝马，而品牌也是一辆车本身的重要属性特征。但当你想要给汽车喷漆，换坐垫，或者更换音响时，这些功能是互相可能兼容的，并且他们的存在不会影响车的核心属性：那就是他是一辆什么车。这时你就可以定义一个装饰器：喷了漆的车。不管他装饰的车是宝马还是奥迪，他的喷漆效果都可以实现。

再回到这个例子中，我们看到的仅仅是一个ConcreteComponent类。在复杂的大型项目中，同一级下的兄弟类通常有很多。当你有五个甚至十个ConcreteComponent时，再想要为每个类都加上“ready？go！”的效果，就要写出五个子类了。毫无疑问这是不合理的。装饰器模式在不影响各个ConcreteComponent核心价值的同时，添加了他特有的装饰效果，具备非常好的通用性，这也是他存在的最大价值。

实战中使用装饰器模式

写这篇博客的初衷也是恰好在工作中使用到了这个模式，觉得非常好用。需求大致是这样：采用sls服务监控项目日志，以Json的格式解析，所以需要将项目中的日志封装成json格式再打印。现有的日志体系采用了log4j + slf4j框架搭建而成。调用起来是这样的:

1
2

private static final Logger logger = LoggerFactory.getLogger(Component.class);
logger.error(string);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
 * logger decorator for other extension 
 * this class have no specific implementation
 * just for a decorator definition
 * @author jzb
 *
 */
public class DecoratorLogger implements Logger {

    public Logger logger;

    public DecoratorLogger(Logger logger) {

        this.logger = logger;
    }
　　　　
    @Override
    public void error(String str) {}

    @Override
    public void info(String str) {}
        
    //省略其他默认实现
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

/**
 * json logger for formatted output 
 * @author jzb
 *
 */
public class JsonLogger extends DecoratorLogger {
public JsonLogger(Logger logger) {
        
        super(logger);
    }
        
    @Override
    public void info(String msg) {

        JSONObject result = composeBasicJsonResult();
        result.put("MESSAGE", msg);
        logger.info(result.toString());
    }
    
    @Override
    public void error(String msg) {
        
        JSONObject result = composeBasicJsonResult();
        result.put("MESSAGE", msg);
        logger.error(result.toString());
    }
    
    public void error(Exception e) {

        JSONObject result = composeBasicJsonResult();
        result.put("EXCEPTION", e.getClass().getName());
        String exceptionStackTrace = ExceptionUtils.getStackTrace(e);    
        result.put("STACKTRACE", exceptionStackTrace);
        logger.error(result.toString());
    }
    
    public static class JsonLoggerFactory {
        
        @SuppressWarnings("rawtypes")
        public static JsonLogger getLogger(Class clazz) {

            Logger logger = LoggerFactory.getLogger(clazz);
            return new JsonLogger(logger);
        }
    }
    
    private JSONObject composeBasicJsonResult() {
        //拼装了一些运行时信息
    }
}

另外，为了在新老交替的过程中尽量不改变太多的代码和使用方式。我又在JsonLogger中加入了一个内部的工厂类JsonLoggerFactory（这个类转移到DecoratorLogger中可能更好一些），他包含一个静态方法，用于提供对应的JsonLogger实例。最终在新的日志体系中，使用方式如下：

1
2

private static final Logger logger = JsonLoggerFactory.getLogger(Component.class);
logger.error(string);

代理模式

代理类成为实际想调用对象的中间件，可以控制对实际调用对象的访问权限；维护实际调用对象的一个引用。

原型模式

创建好了一个实例，然后用这个实例，通过克隆方式创建另一个同类型的实例，而不必关心这个新实例是如何创建的。

原型模式使用时需要注意浅拷贝与深拷贝的问题。

建造者模式

每个对象都具备自己的功能，但是，它们的创建方式却是一样的。这个时候就需要中间这个建造者类来负责功能对象实例的创建。在调用端只需调用特定的方法即可。

这个和策略模式有点类似。

抽象工厂模式

使用该功能类的功能类，利用抽象工厂去创建该功能类的实例。这样的好处在于尽可能的避免去创建功能的实例。
更牛逼的做法就是使用反射去创建这个功能类的实例，在调用端就一点都不需要知道要去实例化那个具体的功能类。这当然不是抽象工厂模式独有的。
抽象工厂模式就变得比工厂模式更为复杂，就像上面提到的缺点一样，工厂模式和简单工厂模式要求产品子类必须要是同一类型的，拥有共同的方法，这就限制了产品子类的扩展。于是为了更加方便的扩展，抽象工厂模式就将同一类的产品子类归为一类，让他们继承同一个抽象子类，我们可以把他们一起视作一组，然后好几组产品构成一族。

此时，客户端要使用时必须知道是哪一个工厂并且是哪一组的产品抽象类。每一个工厂子类负责产生一族产品，而子类的一种方法产生一种类型的产品。在客户端看来只有AbstractProductA和AbstractProductB两种产品，使用的时候也是直接使用这两种产品。而通过工厂来识别是属于哪一族产品。

产品ProductA_1和ProductB_1构成一族产品，对应于有Factory1来创建，也就是说Factory1总是创建的ProductA_1和ProductB_1的产品，在客户端看来只需要知道是哪一类工厂和产品组就可以了。一般来说， ProductA_1和ProductB_1都是适应同一种环境的，所以他们会被归为一族。

常用的场景
例如Linux和windows两种操作系统下，有2个挂件A和B，他们在Linux和Windows下面的实现方式不同，Factory1负责产生能在Linux下运行的挂件A和B，Factory2负责产生能在Windows下运行的挂件A和B，这样如果系统环境发生变化了，我们只需要修改工厂就行了。

优点

1. 封装了产品的创建，使得不需要知道具体是哪种产品，只需要知道是哪个工厂就行了。
2. 可以支持不同类型的产品，使得模式灵活性更强。
3. 可以非常方便的使用一族中间的不同类型的产品。

缺点

1. 结构太过臃肿，如果产品类型比较多，或者产品族类比较多，就会非常难于管理。
2. 每次如果添加一组产品，那么所有的工厂类都必须添加一个方法，这样违背了开放-封闭原则。所以一般适用于产品组合产品族变化不大的情况。

抽象工厂代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    /// 抽象工厂类
    /// </summary>
    public abstract class AbstractEquipment
    {
        /// <summary>
        /// 抽象方法： 创建一辆车
        /// </summary>
        /// <returns></returns>
        public abstract AbstractCar CreateCar();

        /// <summary>
        /// 抽象方法： 创建背包
        /// </summary>
        /// <returns></returns>
        public abstract AbstractBackpack CreateBackpack();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    /// 抽象产品: 车抽象类
    /// </summary>
    public abstract class AbstractCar
    {
        /// <summary>
        /// 车的类型属性
        /// </summary>
        public abstract string Type
        {
            get;
        }

        /// <summary>
        /// 车的颜色属性
        /// </summary>
        public abstract string Color
        {
            get;
        }
    }

    /// <summary>
    /// 抽象产品: 背包抽象类
    /// </summary>
    public abstract class AbstractBackpack
    {
        /// <summary>
        /// 包的类型属性
        /// </summary>
        public abstract string Type
        {
            get;
        }

        /// <summary>
        /// 包的颜色属性
        /// </summary>
        public abstract string Color
        {
            get;
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    /// 运动装备
    /// </summary>
    public class SportEquipment : AbstractEquipment
    {
        public override AbstractCar CreateCar()
        {
            return new SportCar();
        }

        public override AbstractBackpack CreateBackpack()
        {
            return new SportBackpack();
        }
    }

    /// <summary>
    /// 越野装备  这里就不添加了，同运动装备一个原理，demo里只演示一个，实际项目中可以按需添加
    /// </summary>
    //public class JeepEquipment : AbstractEquipment
    //{
    //    public override AbstractCar CreateCar()
    //    {
    //        return new JeeptCar();
    //    }

    //    public override AbstractBackpack CreateBackpack()
    //    {
    //        return new JeepBackpack();
    //    }
    //}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

namespace CNBlogs.DesignPattern.Common
{
    /// <summary>
    /// 跑车
    /// </summary>
    public class SportCar : AbstractCar
    {
        private string type = "Sport";
        private string color = "Red";

        /// <summary>
        /// 重写基类的Type属性
        /// </summary>
        public override string Type
        {
            get
            {
                return type;
            }
        }

        /// <summary>
        /// 重写基类的Color属性
        /// </summary>
        public override string Color
        {
            get
            {
                return color;
            }
        }
    }

    /// <summary>
    /// 运动背包
    /// </summary>
    public class SportBackpack : AbstractBackpack
    {
        private string type = "Sport";
        private string color = "Red";

        /// <summary>
        /// 重写基类的Type属性
        /// </summary>
        public override string Type
        {
            get
            {
                return type;
            }
        }

        /// <summary>
        /// 重写基类的Color属性
        /// </summary>
        public override string Color
        {
            get
            {
                return color;
            }
        }
    }
}
//具体产品可以有很多很多， 至于越野类的具体产品这里就不列出来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

namespace CNBlogs.DesignPattern.Common
{
    public class CreateEquipment
    {
        private AbstractCar fanCar;
        private AbstractBackpack fanBackpack;
        public CreateEquipment(AbstractEquipment equipment)
        {
            fanCar = equipment.CreateCar();
            fanBackpack = equipment.CreateBackpack();
        }

        public void ReadyEquipment()
        {
            Console.WriteLine(string.Format("老范背着{0}色{1}包开着{2}色{3}车。", 
                fanBackpack.Color, 
                fanBackpack.Type,
                fanCar.Color,
                fanCar.Type
                ));
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

//------------------------------------------------------------------------------
// <copyright file="Program.cs" company="CNBlogs Corporation">
//     Copyright (C) 2015-2016 All Rights Reserved
//     原博文地址： http://www.cnblogs.com/toutou/
//     作      者: 请叫我头头哥
// </copyright> 
//------------------------------------------------------------------------------
namespace CNBlogs.DesignPattern
{
    using System;
    using System.Configuration;
    using System.Reflection;

    using CNBlogs.DesignPattern.Common;

    class Program
    {
        static void Main(string[] args)
        {
            // ***具体app.config配置如下*** //
            //<add key="assemblyName" value="CNBlogs.DesignPattern.Common"/>
            //<add key="nameSpaceName" value="CNBlogs.DesignPattern.Common"/>
            //<add key="typename" value="SportEquipment"/>
            // 创建一个工厂类的实例
            string assemblyName = ConfigurationManager.AppSettings["assemblyName"];
            string fullTypeName = string.Concat(ConfigurationManager.AppSettings["nameSpaceName"], ".", ConfigurationManager.AppSettings["typename"]);
            AbstractEquipment factory = (AbstractEquipment)Assembly.Load(assemblyName).CreateInstance(fullTypeName);
            CreateEquipment equipment = new CreateEquipment(factory);
            equipment.ReadyEquipment();
            Console.Read();
        }
    }
}

外观模式

外观模式：为外界调用提供一个统一的接口，把其他类中需要用到的方法提取出来，由外观类进行调用。然后在调用段实例化外观类，以间接调用需要的方法。这种方式形式上和代理模式有异曲同工之妙。

模板模式

模板模式：其实就是抽象出各个具体操作类的公共操作方法，在子类重新实现,然后使用子类去实例化父类。这个模板类其实可以使用接口替换。事实上接口才是专门用来定义操作规范。当然，当有些公共方法，各个子类均有一致需求，此时就不应使用接口，使用抽象类。

状态模式

一个方法的判断逻辑太长，就不容易修改。方法过长，其本质就是，就是本类在不同条件下的状态转移。状态模式，就是将这些判断分开到各个能表示当前状态的独立类中。

备忘录模式

备忘录模式：事实上我觉得这个东西没什么用，按照这种方式进行备份，会因为值类型与引用类型的不同而导致数据丢失。

适配器模式

适配器模式：其实就是代理模式的一个变种，代码的编写方式都差不多。只是，使用这两种模式的出发点不一样，导致这两种模式产生了细微的差别。

组合模式

当对象或系统之间出现部分与整体，或类似树状结构的情况时，考虑组合模式。相对装饰模式来说，这两个有异曲同工之妙，都强调对象间的组合，但是，装饰模式同时强调组合的顺序，而组合模式则是随意组合与移除。

单例模式

能避免同一对象被反复实例化。比如说，访问数据库的连接对象就比普通对象实例化的时间要长;WCF中，维护服务器端远程对象的创建等，这类情况，很有必要用单例模式进行处理对象的实例化。

单例模式也称为单件模式、单子模式，可能是使用最广泛的设计模式。其意图是保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。有很多地方需要这样的功能模块，如系统的日志输出，GUI应用必须是单鼠标，MODEM的联接需要一条且只需要一条电话线，操作系统只能有一个窗口管理器，一台PC连一个键盘。

单例模式有许多种实现方法，在C++中，甚至可以直接用一个全局变量做到这一点，但这样的代码显的很不优雅。 使用全局对象能够保证方便地访问实例，但是不能保证只声明一个对象——也就是说除了一个全局实例外，仍然能创建相同类的本地实例。
《设计模式》一书中给出了一种很不错的实现，定义一个单例类，使用类的私有静态指针变量指向类的唯一实例，并用一个公有的静态方法获取该实例。

单例模式通过类本身来管理其唯一实例，这种特性提供了解决问题的方法。唯一的实例是类的一个普通对象，但设计这个类时，让它只能创建一个实例并提供对此实例的全局访问。唯一实例类Singleton在静态成员函数中隐藏创建实例的操作。习惯上把这个成员函数叫做Instance()，它的返回值是唯一实例的指针。
定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class CSingleton
{
private:
	CSingleton()   //构造函数是私有的
	{
	}
	static CSingleton *m_pInstance;
public:
	static CSingleton * GetInstance()
	{
		if(m_pInstance == NULL)  //判断是否第一次调用
			m_pInstance = new CSingleton();
		return m_pInstance;
	}
};

1
2
3

CSingleton* p1 = CSingleton :: GetInstance();
CSingleton* p2 = p1->GetInstance();
CSingleton & ref = * CSingleton :: GetInstance();

单例类CSingleton有以下特征：

• 它有一个指向唯一实例的静态指针m_pInstance，并且是私有的；
• 它有一个公有的函数，可以获取这个唯一的实例，并且在需要的时候创建该实例；
• 它的构造函数是私有的，这样就不能从别处创建该类的实例。

大多数时候，这样的实现都不会出现问题。有经验的读者可能会问，m_pInstance指向的空间什么时候释放呢？更严重的问题是，该实例的析构函数什么时候执行？
如果在类的析构行为中有必须的操作，比如关闭文件，释放外部资源，那么上面的代码无法实现这个要求。我们需要一种方法，正常的删除该实例。
可以在程序结束时调用GetInstance()，并对返回的指针掉用delete操作。这样做可以实现功能，但不仅很丑陋，而且容易出错。因为这样的附加代码很容易被忘记，而且也很难保证在delete之后，没有代码再调用GetInstance函数。
一个妥善的方法是让这个类自己知道在合适的时候把自己删除，或者说把删除自己的操作挂在操作系统中的某个合适的点上，使其在恰当的时候被自动执行。
我们知道，程序在结束的时候，系统会自动析构所有的全局变量。事实上，系统也会析构所有的类的静态成员变量，就像这些静态成员也是全局变量一样。利用这个特征，我们可以在单例类中定义一个这样的静态成员变量，而它的唯一工作就是在析构函数中删除单例类的实例。如下面的代码中的CGarbo类（Garbo意为垃圾工人）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class CSingleton
{
private:
	CSingleton()
	{
	}
	static CSingleton *m_pInstance;
	class CGarbo   //它的唯一工作就是在析构函数中删除CSingleton的实例
	{
	public:
		~CGarbo()
		{
			if(CSingleton::m_pInstance)
				delete CSingleton::m_pInstance;
		}
	};
	static CGarbo Garbo;  //定义一个静态成员变量，程序结束时，系统会自动调用它的析构函数
public:
	static CSingleton * GetInstance()
	{
		if(m_pInstance == NULL)  //判断是否第一次调用
			m_pInstance = new CSingleton();
		return m_pInstance;
	}
};

• 在单例类内部定义专有的嵌套类；
• 在单例类内定义私有的专门用于释放的静态成员；
• 利用程序在结束时析构全局变量的特性，选择最终的释放时机；
• 使用单例的代码不需要任何操作，不必关心对象的释放。

但是添加一个类的静态对象，总是让人不太满意，所以有人用如下方法来重新实现单例和解决它相应的问题，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

class CSingleton
{
private:
	CSingleton()   //构造函数是私有的
	{
	}
public:
	static CSingleton & GetInstance()
	{
		static CSingleton instance;   //局部静态变量
		return instance;
	}
};

1
2
3
4
5
6
7
8
9
10
11
12
13

class CSingleton
{
private:
	CSingleton()   //构造函数是私有的
	{
	}
public:
	static CSingleton * GetInstance()
	{
		static CSingleton instance;   //局部静态变量
		return &instance;
	}
};

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class CSingleton
{
private:
	CSingleton()   //构造函数是私有的
	{
	}
	CSingleton(const CSingleton &);
	CSingleton & operator = (const CSingleton &);
public:
	static CSingleton & GetInstance()
	{
		static CSingleton instance;   //局部静态变量
		return instance;
	}
};

考虑到线程安全、异常安全，可以做以下扩展

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

class Lock
{
private:       
	CCriticalSection m_cs;
public:
	Lock(CCriticalSection  cs) : m_cs(cs)
	{
		m_cs.Lock();
	}
	~Lock()
	{
		m_cs.Unlock();
	}
};
 
class Singleton
{
private:
	Singleton();
	Singleton(const Singleton &);
	Singleton& operator = (const Singleton &);
 
public:
	static Singleton *Instantialize();
	static Singleton *pInstance;
	static CCriticalSection cs;
};
 
Singleton* Singleton::pInstance = 0;
 
Singleton* Singleton::Instantialize()
{
	if(pInstance == NULL)
	{   //double check
		Lock lock(cs);           //用lock实现线程安全，用资源管理类，实现异常安全
		//使用资源管理类，在抛出异常的时候，资源管理类对象会被析构，析构总是发生的无论是因为异常抛出还是语句块结束。
		if(pInstance == NULL)
		{
			pInstance = new Singleton();
		}
	}
	return pInstance;
}

迭代器模式

提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。

Foreach就是这种模式应用的代表。

职责链模式

职责链模式：就是一个将请求或命令进行转发的流程，类似工作流。并且，也非常类似状态模式，它们共同的特点就是将一个复杂的判断逻辑，转移到各个子类，然后在由子类进行简单判断。

状态模式与职责链模式的区别：状态模式是让各个状态对象自己知道其下一个处理的对象是谁，即在编译时便设定好了的；而职责链模式中的各个对象并不指定其下一个处理的对象到底是谁，只有在客户端才设定。

命令模式

当有客户端发送了一系列的命令或请求，去要求某个对象实现什么操作，可使用命令模式，相当于多个命令发给一个对象。

这一点和观察者模式非常的类似。观察者模式也是某个对象，发出消息，然后由中间对象通知观察者然后去做什么，封装的是要执行操作的对象。而命令模式，则是将各个操作封装成类，然后告知某个对象该做什么。两者的区别是封装的角度不同。

桥接模式

依据合成/聚合原则，优先使用类之间的不同组合，来实现各个类要表现的功能,而不是使用继承。比如说：继承会延续父类的功能，然而，并不是所有的子类都需要这样的功能，但是抽象出的东西在父类，导致子类又必须要实现它，这样，父类就越来越庞大，子类又多了很多不必要的东西。因此，桥接模式更强调类之间的组合从而实现解耦。

对比组合模式，它更强调的是部分与整体间的组合，桥接模式强调的是平行级别上不同类的组合。

解释器模式

举例：写好了C#代码，VB代码，此时需要个编译器来编译。这时，这个编译器就相当于解释器，解释好了交给CPU执行。

解释器跟适配器模式有点类似，但是，适配器模式不需要预先知道要适配的规则，解释器是根据规则去执行解释。

享元模式

享元模式其实是为了避免创建过多的数据对象。比如此列：在象棋中只有红黑双方，红棋子只是红棋中的一颗，很多红棋其实可以使用一个红棋对象表示即可，在外部只需公开该棋的状态即可区分那个红棋，从而达到减少内存消耗的目的。

中介者模式

中介者模式：中介者类唯一要干的事情就是给各个成员对象发出通知。因此，中介者事先就应该知道有哪些成员。

中介者模式和代理模式，观察者模式非常的像。但是其它两种模式在调用的时候，并不需要事先设置那个类被代理，或是事先那些对象需要被通知。

访问者模式

在不改变原有代码的结构上，又想去影响原来的类，或是访问原来类的成员，此时就可以使用访问者模式。但需要注意的是：事先需要构造好那些要访问的对象的对象结构。这个结构在访问者类中去维护。

观察者模式

就是消息订阅—发布模式。本来原始的状况是需要在观察者类内部设置需要通知的对象。结果现在出现了事件。定义委托来通知其他对象，显得更简洁。

进程组

一个或多个进程的集合

eg：显示子进程与父进程的进程组id

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    pid_t pid;

    if ((pid=fork())<0) {
        printf("fork error!");
    }else if (pid==0) {
        printf("The child process PID is %d.\n",getpid());
        printf("The Group ID is %d.\n",getpgrp());
        printf("The Group ID is %d.\n",getpgid(0));
        printf("The Group ID is %d.\n",getpgid(getpid()));
        exit(0);
    }

    sleep(3);
    printf("The parent process PID is %d.\n",getpid());
    printf("The Group ID is %d.\n",getpgrp());

    return 0;
}

进程组id = 父进程id，即父进程为组长进程

组长进程

• 组长进程标识: 其进程组ID==其进程ID
• 组长进程可以创建一个进程组，创建该进程组中的进程，然后终止
• 只要进程组中有一个进程存在，进程组就存在，与组长进程是否终止无关
• 进程组生存期: 进程组创建到最后一个进程离开(终止或转移到另一个进程组)

一个进程可以为自己或子进程设置进程组ID，setpgid()加入一个现有的进程组或创建一个新进程组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    pid_t pid;

    if ((pid=fork())<0) {
        printf("fork error!");
        exit(1);
    }else if (pid==0) {
        printf("The child process PID is %d.\n",getpid());
        printf("The Group ID of child is %d.\n",getpgid(0)); // 返回组id
        sleep(5);
        printf("The Group ID of child is changed to %d.\n",getpgid(0));
        exit(0);
    }

    sleep(1);
    setpgid(pid,pid); // 改变子进程的组id为子进程本身
    
    sleep(5);
    printf("The parent process PID is %d.\n",getpid());
    printf("The parent of parent process PID is %d.\n",getppid());
    printf("The Group ID of parent is %d.\n",getpgid(0));
    setpgid(getpid(),getppid()); // 改变父进程的组id为父进程的父进程
    printf("The Group ID of parent is changed to %d.\n",getpgid(0));

    return 0;
}

会话

一个或多个进程组的集合，开始于用户登录，终止与用户退出，此期间所有进程都属于这个会话期

建立新会话：setsid()函数。该调用进程是组长进程，则出错返回，先调用fork, 父进程终止，子进程调用，该调用进程不是组长进程，则创建一个新会话。

• 该进程变成新会话首进程(session header)
• 该进程成为一个新进程组的组长进程。
• 该进程没有控制终端，如果之前有，则会被中断

组长进程不能成为新会话首进程，新会话首进程必定会成为组长进程…

会话ID:会话首进程的进程组ID。获取会话ID: getsid()函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    pid_t pid;

    if ((pid=fork())<0) {
        printf("fork error!");
        exit(1);
    }else if (pid==0) {
        printf("The child process PID is %d.\n",getpid());
        printf("The Group ID of child is %d.\n",getpgid(0));
        printf("The Session ID of child is %d.\n",getsid(0));
        sleep(10);
        setsid(); // 子进程非组长进程，故其成为新会话首进程，且成为组长进程。该进程组id即为会话进程
        printf("Changed:\n");
        printf("The child process PID is %d.\n",getpid());
        printf("The Group ID of child is %d.\n",getpgid(0));
        printf("The Session ID of child is %d.\n",getsid(0));
        sleep(20);
        exit(0);
    }

    return 0;
}

在子进程中调用setsid()后，子进程成为新会话首进程，且成为一个组长进程，其进程组id等于会话id

守护进程

Linux大多数服务都是通过守护进程实现的，完成许多系统任务

• 0: 调度进程，称为交换进程(swapper),内核一部分，系统进程
• 1: init进程, 内核调用，负责内核启动后启动Linux系统

让某个进程不因为用户、终端或者其他的变化而受到影响，那么就必须把这个进程变成一个守护进程

守护进程编程步骤

• 创建子进程，父进程退出
  • 所有工作在子进程中进行
  • 形式上脱离了控制终端
• 在子进程中创建新会话
  • setsid()函数
  • 使子进程完全独立出来，脱离控制
• 改变当前目录为根目录
  • chdir()函数
  • 防止占用可卸载的文件系统
  • 也可以换成其它路径
• 重设文件权限掩码
  • umask()函数
  • 防止继承的文件创建屏蔽字拒绝某些权限
  • 增加守护进程灵活性
• 关闭文件描述符
  • 继承的打开文件不会用到，浪费系统资源，无法卸载
  • getdtablesize()
  • 返回所在进程的文件描述符表的项数，即该进程打开的文件数目

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <fcntl.h>

int main() {
    pid_t pid;
    int i,fd;
    char *buf="This is a daemon program.\n";

    if ((pid=fork())<0) {
        printf("fork error!");
        exit(1);
    }else if (pid>0)  // fork且退出父进程
        exit(0);
    
    setsid();    // 在子进程中创建新会话。
    chdir("/");  // 设置工作目录为根
    umask(0);    // 设置权限掩码
    for(i=0;i<getdtablesize();i++)  //getdtablesize返回子进程文件描述符表的项数
        close(i);                // 关闭这些不将用到的文件描述符

    while(1) {// 死循环表征它将一直运行
// 以读写方式打开"/tmp/daemon.log"，返回的文件描述符赋给fd
        if ((fd=open("/tmp/daemon.log",O_CREAT|O_WRONLY|O_APPEND,0600))<0) {
            printf("Open file error!\n");
            exit(1);
        }
        // 将buf写到fd中
        write(fd,buf,strlen(buf)+1);
        close(fd);
        sleep(10);
        printf("Never output!\n");
    }

    return 0;
}

因为stdout被关掉了，所以“Never ouput!”不会输出。
查看/tmp/daemon.log，说明该程序一直在运行

fork()

fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，linux中引入了“写时复制“技术，也就是只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。在fork之后exec之前两个进程用的是相同的物理空间（内存区），子进程的代码段、数据段、堆栈都是指向父进程的物理空间，也就是说，两者的虚拟空间不同，但其对应的物理空间是同一个。当父子进程中有更改相应段的行为发生时，再为子进程相应的段分配物理空间，如果不是因为exec，内核会给子进程的数据段、堆栈段分配相应的物理空间（至此两者有各自的进程空间，互不影响），而代码段继续共享父进程的物理空间（两者的代码完全相同）。而如果是因为exec，由于两者执行的代码不同，子进程的代码段也会分配单独的物理空间。

fork之后内核会通过将子进程放在队列的前面，以让子进程先执行，以免父进程执行导致写时复制，而后子进程执行exec系统调用，因无意义的复制而造成效率的下降。
fork时子进程获得父进程数据空间、堆和栈的复制，所以变量的地址（当然是虚拟地址）也是一样的。

每个进程都有自己的虚拟地址空间，不同进程的相同的虚拟地址显然可以对应不同的物理地址。因此地址相同（虚拟地址）而值不同没什么奇怪。

具体过程是这样的：
fork子进程完全复制父进程的栈空间，也复制了页表，但没有复制物理页面，所以这时虚拟地址相同，物理地址也相同，但是会把父子共享的页面标记为“只读”（类似mmap的private的方式），如果父子进程一直对这个页面是同一个页面，知道其中任何一个进程要对共享的页面“写操作”，这时内核会复制一个物理页面给这个进程使用，同时修改页表。而把原来的只读页面标记为“可写”，留给另外一个进程使用。

这就是所谓的“写时复制”。正因为fork采用了这种写时复制的机制，所以fork出来子进程之后，父子进程哪个先调度呢？内核一般会先调度子进程，因为很多情况下子进程是要马上执行exec，会清空栈、堆。。这些和父进程共享的空间，加载新的代码段。。。，这就避免了“写时复制”拷贝共享页面的机会。如果父进程先调度很可能写共享页面，会产生“写时复制”的无用功。所以，一般是子进程先调度滴。

子进程与父进程之间除了代码是共享的之外，堆栈数据和全局数据均是独立的。

pid = fork()返回两次，第一次父进程，第二次子进程：

1
2
3

[root@localhost timetest]# ./test
This is parent process: 4016
This is child process: 4017

注意：这里不是绝对的先返回父进程的pid，具体先执行那个进程，要看操作系统的进程调度算法。

操作系统创建一个新的进程（子进程），并且在进程表中相应为它建立一个新的表项。新进程和原有进程的可执行程序是同一个程序；上下文和数据，绝大部分就是原进程（父进程）的拷贝，但它们是两个相互独立的进程！此时程序寄存器pc，在父、子进程的上下文中都声称，这个进程目前执行到fork调用即将返回（此时子进程不占有CPU，子进程的pc不是真正保存在寄存器中，而是作为进程上下文保存在进程表中的对应表项内）。问题是怎么返回，在父子进程中就分道扬镳。

父进程继续执行，操作系统对fork的实现，使这个调用在父进程中返回刚刚创建的子进程的pid（一个正整数），所以下面的if语句中pid<0, pid==0的两个分支都不会执行。所以输出i am the parent process…

子进程在之后的某个时候得到调度，它的上下文被换入，占据 CPU，操作系统对fork的实现，使得子进程中fork调用返回0。所以在这个进程（注意这不是父进程了哦，虽然是同一个程序，但是这是同一个程序的另外一次执行，在操作系统中这次执行是由另外一个进程表示的，从执行的角度说和父进程相互独立）中pid=0。这个进程继续执行的过程中，if语句中 pid<0不满足，但是pid= =0是true。所以输出i am the child process…

为什么看上去程序中互斥的两个分支都被执行了？在一个程序的一次执行中，这当然是不可能的；但是你看到的两行输出是来自两个进程，这两个进程来自同一个程序的两次执行。

fork之后，操作系统会复制一个与父进程完全相同的子进程，虽说是父子关系，但是在操作系统看来，他们更像兄弟关系，这2个进程共享代码空间，但是数据空间是互相独立的，子进程数据空间中的内容是父进程的完整拷贝，指令指针也完全相同，但只有一点不同，如果fork成功，子进程中fork的返回值是0，父进程中fork的返回值是子进程的进程号，如果fork不成功，父进程会返回错误。

可以这样想象，2个进程一直同时运行，而且步调一致，在fork之后，他们分别作不同的工作，也就是分岔了。这也是fork为什么叫fork的原因。

在程序段里用了fork()之后程序出了分岔，派生出了两个进程。具体哪个先运行就看该系统的调度算法了。

如果需要父子进程协同，可以通过原语的办法解决。

父进程为什么要创建子进程呢?

前面我们已经说过了Linux是一个多用户操作系统,在同一时间会有许多的用户在争夺系统的资源.有时进程为了早一点完成任务就创建子进程来争夺资源. 一旦子进程被创建,父子进程一起从fork处继续执行,相互竞争系统的资源.有时候我们希望子进程继续执行,而父进程阻塞,直到子进程完成任务.这个时候我们可以调用wait或者waitpid系统调用.

对子进程来说，fork返回给它0,但它的pid绝对不会是0；之所以fork返回0给它，是因为它随时可以调用getpid()来获取自己的pid；

fork之后父子进程除非采用了同步手段，否则不能确定谁先运行，也不能确定谁先结束。认为子进程结束后父进程才从fork返回的，这是不对的，fork不是这样的，vfork才这样。

为什么返回0呢

• 首先必须有一点要清楚，函数的返回值是储存在寄存器eax中的。
• 其次，当fork返回时，新进程会返回0是因为在初始化任务结构时，将eax设置为0；
• 在fork中，把子进程加入到可运行的队列中，由进程调度程序在适当的时机调度运行。也就是从此时开始，当前进程分裂为两个并发的进程。
• 无论哪个进程被调度运行，都将继续执行fork函数的剩余代码，执行结束后返回各自的值。

【NOTE5】
对于fork来说，父子进程共享同一段代码空间，所以给人的感觉好像是有两次返回，其实对于调用fork的父进程来说，如果fork出来的子进程没有得到调度，那么父进程从fork系统调用返回，同时分析sys_fork知道，fork返回的是子进程的id。再看fork出来的子进程，由 copy_process函数可以看出，子进程的返回地址为ret_from_fork（和父进程在同一个代码点上返回），返回值直接置为0。所以当子进程得到调度的时候，也从fork返回，返回值为0。

关键注意两点：

1. fork返回后，父进程或子进程的执行位置。（首先会将当前进程eax的值做为返回值）
2. 两次返回的pid存放的位置。（eax中）

pid=fork()，当执行这一句时，当前进程进入fork()运行，此时，fork()内会用一段嵌入式汇编进行系统调用：int 0x80。这时进入内核根据此前写入eax的系统调用功能号便会运行sys_fork系统调用。接着，sys_fork中首先会调用C函数find_empty_process产生一个新的进程，然后会调用C函数 copy_process将父进程的内容复制给子进程，但是子进程tss中的eax值赋值为0（这也是为什么子进程中返回0的原因），当赋值完成后， copy_process会返回新进程（该子进程）的pid，这个值会被保存到eax中。这时子进程就产生了，此时子进程与父进程拥有相同的代码空间，程序指针寄存器eip指向相同的下一条指令地址，当fork正常返回调用其的父进程后，因为eax中的值是新创建的子进程号，所以，fork()返回子进程号，执行else（pid > 0）;当产生进程切换运行子进程时，首先会恢复子进程的运行环境即装入子进程的tss任务状态段，其中的eax 值(copy_process中置为0)也会被装入eax寄存器，所以，当子进程运行时，fork返回的是0执行if(pid==0)。

多进程

首先，先来讲一下fork之后，发生了什么事情。

由fork创建的新进程被称为子进程（child process）。该函数被调用一次，但返回两次。两次返回的区别是子进程的返回值是0，而父进程的返回值则是新进程（子进程）的进程 id。将子进程id返回给父进程的理由是：因为一个进程的子进程可以多于一个，没有一个函数使一个进程可以获得其所有子进程的进程id。对子进程来说，之所以fork返回0给它，是因为它随时可以调用getpid()来获取自己的pid；也可以调用getppid()来获取父进程的id。(进程id 0总是由交换进程使用，所以一个子进程的进程id不可能为0 )。

fork之后，操作系统会复制一个与父进程完全相同的子进程，虽说是父子关系，但是在操作系统看来，他们更像兄弟关系，这2个进程共享代码空间，但是数据空间是互相独立的，子进程数据空间中的内容是父进程的完整拷贝，指令指针也完全相同，子进程拥有父进程当前运行到的位置（两进程的程序计数器pc值相同，也就是说，子进程是从fork返回处开始执行的），但有一点不同，如果fork成功，子进程中fork的返回值是0，父进程中fork的返回值是子进程的进程号，如果fork不成功，父进程会返回错误。
可以这样想象，2个进程一直同时运行，而且步调一致，在fork之后，他们分别作不同的工作，也就是分岔了。这也是fork为什么叫fork的原因

至于哪一个最先运行，可能与操作系统（调度算法）有关，而且这个问题在实际应用中并不重要，如果需要父子进程协同，可以通过原语的办法解决。

常见的通信方式：

1. 管道pipe：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。
2. 命名管道FIFO：有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。
3. 消息队列MessageQueue：消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
4. 共享存储SharedMemory：共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。
5. 信号量Semaphore：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
6. 套接字Socket：套解口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同及其间的进程通信。
7. 信号（sinal）：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。

信号

中断和异常

中断（也称硬件中断）

定义：中断是由其他硬件设备依照CPU时钟周期信号随机产生的。
分类： 可屏蔽中断、非可屏蔽中断
来源：间隔定时器和I/O

异常（也称软件中断）

定义：当指令执行时由CPU控制单元产生的，异常也称为“异步中断”是因为只有在 一条指令终止执行后CPU才会发出中断。
分类： 处理器探测到的异常、故障、陷阱、异常终止、编程异常(也称软中断)、int指令
来源：程序的错误产生的
内核必须处理的异常(例如：缺页和内核服务的请求-int)

异常处理

当发生异常时，CPU控制单元产生一个硬件出错码。CPU根据该中断吗找到中断向量表内的对应向量，根据该向量转到中断处理程序。中断处理程序处理完之后向当前进程发送一个SIG*信号。若进程定义了相应的信号处理程序则转移到相应的程序执行，若没有，则执行内核定义的操作。

中断处理

设备产生中断，PIC（可编程中断控制器）会产生一个对应的中断向量和中断向量表中的每一个中断向量进行比较，转到对应的中断处理程序，中断处理程序进行保存现场，做相关处理，恢复现场，内核调度，返回用户进程。

硬件中断的上半部和下半部及实现方式

硬件中断的分类

• 紧急的 —— 这类中断必须立即执行
• 非紧急的 —— 也必须立即执行
• 非紧急可延迟的 —— 上半部立即执行，下半部延迟执行

硬件中断任务（处理程序）是一个快速、异步、简单地对硬件做出迅速响应并在最短时间内完成必要操作的中断处理程序。硬中断处理程序可以抢占内核任务并且执 行时还会屏蔽同级中断或其它中断，因此中断处理必须要快、不能阻塞。这样一来对于一些要求处理过程比较复杂的任务就不合适在中断任务中一次处理。比如，网卡接收数据的过程中,首先网卡发送中断信号告诉CPU来取数据，然后系统从网卡中读取数据存入系统缓冲区中，再下来解析数据然后送入应用层。这些如果都让中断处理程序来处理显然过程太长，造成新来的中断丢失。因此Linux开发人员将这种任务分割为两个部分，一个叫上底，即中断处理程序，短平快地处理与硬 件相关的操作（如从网卡读数据到系统缓存）；而把对时间要求相对宽松的任务（如解析数据的工作）放在另一个部分执行，这个部分就是我们这里要讲的下半底。

下半底是一种推后执行任务，它将某些不那么紧迫的任务推迟到系统更方便的时刻运行。因为并不是非常紧急，通常还是比较耗时的，因此由系统自行安排运行时机，不在中断服务上下文中执行。内核中实现 下半底的手段经过不断演化，目前已经从最原始的BH(bottom thalf)演生出BH、任务队列（Task queues）、软中断（Softirq）、Tasklet、工作队列（Work queues）（2.6内核中新出现的）。

关于软中断和硬中断的其它解析：

软中断一般是指由指令int引起的“伪”中断动作——给CPU制造一个中断的假象；而硬中断则是实实在在由8259的连线触发的中断。因此，严格的 讲，int与IRQ毫无关系，但二者均与中断向量有关系。int引起的中断，CPU是从指令中取得中断向量号；而IRQ引起的中断，CPU必须从数据线上取回中断号，接下来CPU的工作就一样了：保护现场、根据中断号得到中断处理程序地址、执行中断处理、恢复现场继续执行被中断的指令。

在软中断和硬中断之间的区别是什么？

1. 硬中断是由外部事件引起的因此具有随机性和突发性；软中断是执行中断指令产生的，无面外部施加中断请求信 号，因此中断的发生不是随机的而是由程序安排好的。
2. 硬中断的中断响应周期，CPU需要发中断回合信号（NMI不需要），软中断的中断响应周 期，CPU不需发中断回合信号。
3. 硬中断的中断号是由中断控制器提供的（NMI硬中断中断号系统指定为02H）；软中断的中断号由指令直接给出， 无需使用中断控制器。
4. 硬中断是可屏蔽的（NMI硬中断不可屏蔽），软中断不可屏蔽。

硬中断：

1. 硬中断是由硬件产生的，比如，像磁盘，网卡，键盘，时钟等。每个设备或设备集都有它自己的IRQ（中断请求）。基于IRQ，CPU可以将相应的请求分发到对应的硬件驱动上（注：硬件驱动通常是内核中的一个子程序，而不是一个独立的进程）。
2. 处理中断的驱动是需要运行在CPU上的，因此，当中断产生的时候，CPU会中断当前正在运行的任务，来处理中断。在有多核心的系统上，一个中断通常只能中断一颗CPU（也有一种特殊的情况，就是在大型主机上是有硬件通道的，它可以在没有主CPU的支持下，可以同时处理多个中断。）。
3. 硬中断可以直接中断CPU。它会引起内核中相关的代码被触发。对于那些需要花费一些时间去处理的进程，中断代码本身也可以被其他的硬中断中断。
4. 对于时钟中断，内核调度代码会将当前正在运行的进程挂起，从而让其他的进程来运行。它的存在是为了让调度代码（或称为调度器）可以调度多任务。

软中断：

1. 软中断的处理非常像硬中断。然而，它们仅仅是由当前正在运行的进程所产生的。
2. 通常，软中断是一些对I/O的请求。这些请求会调用内核中可以调度I/O发生的程序。对于某些设备，I/O请求需要被立即处理，而磁盘I/O请求通常可以排队并且可以稍后处理。根据I/O模型的不同，进程或许会被挂起直到I/O完成，此时内核调度器就会选择另一个进程去运行。I/O可以在进程之间产生并且调度过程通常和磁盘I/O的方式是相同。
3. 软中断仅与内核相联系。而内核主要负责对需要运行的任何其他的进程进行调度。一些内核允许设备驱动的一些部分存在于用户空间，并且当需要的时候内核也会调度这个进程去运行。
4. 软中断并不会直接中断CPU。也只有当前正在运行的代码（或进程）才会产生软中断。这种中断是一种需要内核为正在运行的进程去做一些事情（通常为I/O）的请求。有一个特殊的软中断是Yield调用，它的作用是请求内核调度器去查看是否有一些其他的进程可以运行。

信号本质

软中断信号（signal，又简称为信号）用来通知进程发生了异步事件。在软件层次上是对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是进程间通信机制中唯一的异步通信机制，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。进程之间可以互相通过系统调用kill发送软中断信号。内核也可以因为内部事件而给进程发送信号，通知进程发生了某个事件。信号机制除了基本通知功能外，还可以传递附加信息。

产生信号的条件主要有：

1. 用户在终端 按下某些键时，终端驱动程序会发送信号给前台进程，例如Ctrl-C产生SIGINT信 号，Ctrl-/产生SIGQUIT信号，Ctrl-Z产生SIGTSTP信号。
2. 硬件异常产生信号，这些条件由硬件检测到并通知内核，然后内核向当前进程发送适当的信号。例如当前进程执行了 除以0的指令，CPU的运算单元会产生异常，内核将这个异常解释为SIGFPE信号发送给进 程。再比如当前进程访问了非法内存地址，，MMU会产生异常，内核将这个异常解释为SIGSEGV信 号发送给进程。
3. 一个进程调用kill(2)函数可以发送信 号给另一个进程。
4. 可以用kill(1)命令发送信号给某个 进程，kill(1)命令也是调用kill(2)函 数实现的，如果不明确指定信号则发送SIGTERM信号，该信号的默认处理动作是终止进程。
5. 当内核检测到某种软件条件发生时也可以通过信号通知进程，例如闹钟超时产生SIGALRM信 号，向读端已关闭的管道写数据时产生SIGPIPE信号。

收到信号的进程对各种信号有不同的处理方法。处理方法可以分为三类：

• 第一种是类似中断的处理程序，对于需要处理的信号，进程可以指定处理函数，由该函数来处理。
• 第二种方法是，忽略某个信号，对该信号不做任何处理，就象未发生过一样。
• 第三种方法是，对该信号的处理保留系统的默认值，这种缺省操作，对大部分的信号的缺省操作是使得进程终止。进程通过系统调用signal来指定进程对某个信号的处理行为。

信号的种类

可以从两个不同的分类角度对信号进行分类：

• 可靠性方面：可靠信号与不可靠信号；
• 与时间的关系上：实时信号与非实时信号。

可靠信号与不可靠信号

Linux信号机制基本上是从Unix系统中继承过来的。早期Unix系统中的信号机制比较简单和原始，信号值小于SIGRTMIN的信号都是不可靠信号。这就是”不可靠信号”的来源。它的主要问题是信号可能丢失。

随着时间的发展，实践证明了有必要对信号的原始机制加以改进和扩充。由于原来定义的信号已有许多应用，不好再做改动，最终只好又新增加了一些信号，并在一开始就把它们定义为可靠信号，这些信号支持排队，不会丢失。

信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation()以及信号发送函数sigqueue()的同时，仍然支持早期的signal()信号安装函数，支持信号发送函数kill()。

信号的可靠与不可靠只与信号值有关，与信号的发送及安装函数无关。目前linux中的signal()是通过sigation()函数实现的，因此，即使通过signal()安装的信号，在信号处理函数的结尾也不必再调用一次信号安装函数。同时，由signal()安装的实时信号支持排队，同样不会丢失。

对于目前linux的两个信号安装函数：signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数，而经过signal安装的信号不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。

实时信号与非实时信号

早期Unix系统只定义了32种信号，前32种信号已经有了预定义值，每个信号有了确定的用途及含义，并且每种信号都有各自的缺省动作。如按键盘的CTRL ^C时，会产生SIGINT信号，对该信号的默认反应就是进程终止。后32个信号表示实时信号，等同于前面阐述的可靠信号。这保证了发送的多个实时信号都被接收。

非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号。

信号处理流程

对于一个完整的信号生命周期(从信号发送到相应的处理函数执行完毕)来说，可以分为三个阶段：

• 信号诞生
• 信号在进程中注册
• 信号的执行和注销

信号诞生

信号事件的发生有两个来源：硬件来源(比如我们按下了键盘或者其它硬件故障)；软件来源，最常用发送信号的系统函数是kill, raise, alarm和setitimer以及sigqueue函数，软件来源还包括一些非法运算等操作。

这里按发出信号的原因简单分类，以了解各种信号：

1. 与进程终止相关的信号。当进程退出，或者子进程终止时，发出这类信号。
2. 与进程例外事件相关的信号。如进程越界，或企图写一个只读的内存区域（如程序正文区），或执行一个特权指令及其他各种硬件错误。
3. 与在系统调用期间遇到不可恢复条件相关的信号。如执行系统调用exec时，原有资源已经释放，而目前系统资源又已经耗尽。
4. 与执行系统调用时遇到非预测错误条件相关的信号。如执行一个并不存在的系统调用。
5. 在用户态下的进程发出的信号。如进程调用系统调用kill向其他进程发送信号。
6. 与终端交互相关的信号。如用户关闭一个终端，或按下break键等情况。
7. 跟踪进程执行的信号。

Linux支持的信号列表如下。很多信号是与机器的体系结构相关的

1. SIGHUP：当用户退出Shell时，由该Shell启的发所有进程都退接收到这个信号，默认动作为终止进程。
2. SIGINT：用户按下组合键时，用户端时向正在运行中的由该终端启动的程序发出此信号。默认动作为终止进程。
3. SIGQUIT：当用户按下组合键时产生该信号，用户终端向正在运行中的由该终端启动的程序发出此信号。默认动作为终止进程并产生core文件。
4. SIGILL ：CPU检测到某进程执行了非法指令。默认动作为终止进程并产生core文件。
5. SIGTRAP：该信号由断点指令或其他trap指令产生。默认动作为终止进程并产生core文件。
6. SIGABRT：调用abort函数时产生该信号。默认动作为终止进程并产生core文件。
7. SIGBUS：非法访问内存地址，包括内存地址对齐（alignment）出错，默认动作为终止进程并产生core文件。
8. SIGFPE：在发生致命的算术错误时产生。不仅包括浮点运行错误，还包括溢出及除数为0等所有的算术错误。默认动作为终止进程并产生core文件。
9. SIGKILL：无条件终止进程。本信号不能被忽略、处理和阻塞。默认动作为终止进程。它向系统管理员提供了一种可以杀死任何进程的方法。
10. SIGUSR1：用户定义的信号，即程序可以在程序中定义并使用该信号。默认动作为终止进程。
11. SIGSEGV：指示进程进行了无效的内存访问。默认动作为终止进程并使用该信号。默认动作为终止进程。
12. SIGUSR2：这是另外一个用户定义信号，程序员可以在程序中定义并使用该信号。默认动作为终止进程。
13. SIGPIPE：Broken pipe：向一个没有读端的管道写数据。默认动作为终止进程。
14. SIGALRM：定时器超时，超时的时间由系统调用alarm设置。默认动作为终止进程。
15. SIGTERM：程序结束(terminate)信号，与SIGKILL不同的是，该信号可以被阻塞和处理。通常用来要求程序正常退出。执行Shell命令kill时，缺少产生这个信号。默认动作为终止进程。
16. SIGCHLD：子程序结束时，父进程会收到这个信号。默认动作为忽略该信号。
17. SIGCONT：让一个暂停的进程继续执行。
18. SIGSTOP：停止(stopped)进程的执行。注意它和SIGTERM以及SIGINT的区别：该进程还未结束，只是暂停执行。本信号不能被忽略、处理和阻塞。默认作为暂停进程。
19. SIGTSTP：停止进程的动作，但该信号可以被处理和忽略。按下组合键时发出该信号。默认动作为暂停进程。
20. SIGTTIN：当后台进程要从用户终端读数据时，该终端中的所有进程会收到SIGTTIN信号。默认动作为暂停进程。
21. SIGTTOU：该信号类似于SIGTIN，在后台进程要向终端输出数据时产生。默认动作为暂停进程。
22. SIGURG：套接字（socket）上有紧急数据时，向当前正在运行的进程发出此信号，报告有紧急数据到达。默认动作为忽略该信号。
23. SIGXCPU：进程执行时间超过了分配给该进程的CPU时间，系统产生该信号并发送给该进程。默认动作为终止进程。
24. SIGXFSZ：超过文件最大长度的限制。默认动作为yl终止进程并产生core文件。
25. SIGVTALRM：虚拟时钟超时时产生该信号。类似于SIGALRM，但是它只计算该进程占有用的CPU时间。默认动作为终止进程。
26. SIGPROF：类似于SIGVTALRM，它不仅包括该进程占用的CPU时间还抱括执行系统调用的时间。默认动作为终止进程。
27. SIGWINCH：窗口大小改变时发出。默认动作为忽略该信号。
28. SIGIO：此信号向进程指示发出一个异步IO事件。默认动作为忽略。
29. SIGPWR：关机。默认动作为终止进程。
30. SIGRTMIN~SIGRTMAX：Linux的实时信号，它没有固定的含义(或者说可以由用户自由使用)。注意，Linux线程机制使用了前3个实时信号。所有的实时信号的默认动作都是终止进程。

信号在目标进程中注册

在进程表的表项中有一个软中断信号域，该域中每一位对应一个信号。内核给一个进程发送软中断信号的方法，是在进程所在的进程表项的信号域设置对应于该信号的位。如果信号发送给一个正在睡眠的进程，如果进程睡眠在可被中断的优先级上，则唤醒进程；否则仅设置进程表中信号域相应的位，而不唤醒进程。如果发送给一个处于可运行状态的进程，则只置相应的域即可。

进程的task_struct结构中有关于本进程中未决信号的数据成员：struct sigpending pending

1
2
3
4

struct sigpending{
        struct sigqueue *head, *tail;
        sigset_t signal;
};

1
2
3
4

struct sigqueue{
        struct sigqueue *next;
        siginfo_t info;
}

当一个实时信号发送给一个进程时，不管该信号是否已经在进程中注册，都会被再注册一次，因此，信号不会丢失，因此，实时信号又叫做”可靠信号”。这意味着同一个实时信号可以在同一个进程的未决信号信息链中占有多个sigqueue结构（进程每收到一个实时信号，都会为它分配一个结构来登记该信号信息，并把该结构添加在未决信号链尾，即所有诞生的实时信号都会在目标进程中注册）。

当一个非实时信号发送给一个进程时，如果该信号已经在进程中注册（通过sigset_t signal指示），则该信号将被丢弃，造成信号丢失。因此，非实时信号又叫做”不可靠信号”。这意味着同一个非实时信号在进程的未决信号信息链中，至多占有一个sigqueue结构。

总之信号注册与否，与发送信号的函数（如kill()或sigqueue()等）以及信号安装函数（signal()及sigaction()）无关，只与信号值有关（信号值小于SIGRTMIN的信号最多只注册一次，信号值在SIGRTMIN及SIGRTMAX之间的信号，只要被进程接收到就被注册）

信号的执行和注销

内核处理一个进程收到的软中断信号是在该进程的上下文中，因此，进程必须处于运行状态。当其由于被信号唤醒或者正常调度重新获得CPU时，在其从内核空间返回到用户空间时会检测是否有信号等待处理。如果存在未决信号等待处理且该信号没有被进程阻塞，则在运行相应的信号处理函数前，进程会把信号在未决信号链中占有的结构卸掉。

对于非实时信号来说，由于在未决信号信息链中最多只占用一个sigqueue结构，因此该结构被释放后，应该把信号在进程未决信号集中删除（信号注销完毕）；而对于实时信号来说，可能在未决信号信息链中占用多个sigqueue结构，因此应该针对占用sigqueue结构的数目区别对待：如果只占用一个sigqueue结构（进程只收到该信号一次），则执行完相应的处理函数后应该把信号在进程的未决信号集中删除（信号注销完毕）。否则待该信号的所有sigqueue处理完毕后再在进程的未决信号集中删除该信号。

当所有未被屏蔽的信号都处理完毕后，即可返回用户空间。对于被屏蔽的信号，当取消屏蔽后，在返回到用户空间时会再次执行上述检查处理的一套流程。

内核处理一个进程收到的信号的时机是在一个进程从内核态返回用户态时。所以，当一个进程在内核态下运行时，软中断信号并不立即起作用，要等到将返回用户态时才处理。进程只有处理完信号才会返回用户态，进程在用户态下不会有未处理完的信号。

处理信号有三种类型：

• 进程接收到信号后退出；
• 进程忽略该信号；
• 进程收到信号后执行用户设定用系统调用signal的函数。

当进程接收到一个它忽略的信号时，进程丢弃该信号，就象没有收到该信号似的继续运行。如果进程收到一个要捕捉的信号，那么进程从内核态返回用户态时执行用户定义的函数。而且执行用户定义的函数的方法很巧妙，内核是在用户栈上创建一个新的层，该层中将返回地址的值设置成用户定义的处理函数的地址，这样进程从内核返回弹出栈顶时就返回到用户定义的函数处，从函数返回再弹出栈顶时，才返回原先进入内核的地方。这样做的原因是用户定义的处理函数不能且不允许在内核态下执行（如果用户定义的函数在内核态下运行的话，用户就可以获得任何权限）。

信号的安装

如果进程要处理某一信号，那么就要在进程中安装该信号。安装信号主要用来确定信号值及进程针对该信号值的动作之间的映射关系，即进程将要处理哪个信号；该信号被传递给进程时，将执行何种操作。

linux主要有两个函数实现信号的安装：signal()、sigaction()。其中signal()只有两个参数，不支持信号传递信息，主要是用于前32种非实时信号的安装；而sigaction()是较新的函数（由两个系统调用实现：sys_signal以及sys_rt_sigaction），有三个参数，支持信号传递信息，主要用来与 sigqueue() 系统调用配合使用，当然，sigaction()同样支持非实时信号的安装。sigaction()优于signal()主要体现在支持信号带有参数。

signal()

1
2

#include <signal.h>
void (*signal(int signum, void (*handler))(int)))(int);

如果该函数原型不容易理解的话，可以参考下面的分解方式来理解：

1
2

typedef void (*sighandler_t)(int)；
sighandler_t signal(int signum, sighandler_t handler));

第一个参数指定信号的值，第二个参数指定针对前面信号值的处理，可以忽略该信号（参数设为SIG_IGN）；可以采用系统默认方式处理信号(参数设为SIG_DFL)；也可以自己实现处理方式(参数指定一个函数地址)。

如果signal()调用成功，返回最后一次为安装信号signum而调用signal()时的handler值；失败则返回SIG_ERR。

传递给信号处理例程的整数参数是信号值，这样可以使得一个信号处理例程处理多个信号。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <signal.h>
#include <unistd.h>
#include <stdio.h>
void sigroutine(int dunno)
{ /* 信号处理例程，其中dunno将会得到信号的值 */
        switch (dunno) {
        case 1:
        printf("Get a signal -- SIGHUP ");
        break;
        case 2:
        printf("Get a signal -- SIGINT ");
        break;
        case 3:
        printf("Get a signal -- SIGQUIT ");
        break;
        }
        return;
}

int main() {
        printf("process id is %d ",getpid());
        signal(SIGHUP, sigroutine); //* 下面设置三个信号的处理方法
        signal(SIGINT, sigroutine);
        signal(SIGQUIT, sigroutine);
        for (;;) ;
}

其中信号SIGINT由按下Ctrl-C发出，信号SIGQUIT由按下Ctrl-发出。该程序执行的结果如下：

1
2
3
4
5
6
7
8
9
10
11
12

localhost:~$ ./sig_test
process id is 463
Get a signal -SIGINT //按下Ctrl-C得到的结果
Get a signal -SIGQUIT //按下Ctrl-得到的结果
//按下Ctrl-z将进程置于后台
 [1]+ Stopped ./sig_test
localhost:~$ bg
 [1]+ ./sig_test &
localhost:~$ kill -HUP 463 //向进程发送SIGHUP信号
localhost:~$ Get a signal – SIGHUP
kill -9 463 //向进程发送SIGKILL信号，终止进程
localhost:~$

sigaction()

1
2

#include <signal.h>
int sigaction(int signum,const struct sigaction *act,struct sigaction *oldact));

sigaction函数用于改变进程接收到特定信号后的行为。该函数的第一个参数为信号的值，可以为除SIGKILL及SIGSTOP外的任何一个特定有效的信号（为这两个信号定义自己的处理函数，将导致信号安装错误）。第二个参数是指向结构sigaction的一个实例的指针，在结构sigaction的实例中，指定了对特定信号的处理，可以为空，进程会以缺省方式对信号处理；第三个参数oldact指向的对象用来保存返回的原来对相应信号的处理，可指定oldact为NULL。如果把第二、第三个参数都设为NULL，那么该函数可用于检查信号的有效性。

第二个参数最为重要，其中包含了对指定信号的处理、信号所传递的信息、信号处理函数执行过程中应屏蔽掉哪些信号等等。

sigaction结构定义如下：

1
2
3
4
5
6
7
8

struct sigaction {
	union{
		__sighandler_t _sa_handler;
		void (*_sa_sigaction)(int,struct siginfo *, void *)；
	}_u
	sigset_t sa_mask；
	unsigned long sa_flags；
}

1. 联合数据结构中的两个元素_sa_handler以及*_sa_sigaction指定信号关联函数，即用户指定的信号处理函数。除了可以是用户自定义的处理函数外，还可以为SIG_DFL(采用缺省的处理方式)，也可以为SIG_IGN（忽略信号）。
2. 由_sa_sigaction是指定的信号处理函数带有三个参数，是为实时信号而设的（当然同样支持非实时信号），它指定一个3参数信号处理函数。第一个参数为信号值，第三个参数没有使用，第二个参数是指向siginfo_t结构的指针，结构中包含信号携带的数据值，参数所指向的结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

siginfo_t {
    int si_signo;  /* 信号值，对所有信号有意义*/
    int si_errno;  /* errno值，对所有信号有意义*/
    int si_code;   /* 信号产生的原因，对所有信号有意义*/
    union{                               /* 联合数据结构，不同成员适应不同信号 */
        //确保分配足够大的存储空间
        int _pad[SI_PAD_SIZE];
        //对SIGKILL有意义的结构
        struct{
            ...
        }...
        ... ...
        ... ...                               
        //对SIGILL, SIGFPE, SIGSEGV, SIGBUS有意义的结构
        struct{
            ...
        }...
        ... ...
    }
}

前面在讨论系统调用sigqueue发送信号时，sigqueue的第三个参数就是sigval联合数据结构，当调用sigqueue时，该数据结构中的数据就将拷贝到信号处理函数的第二个参数中。这样，在发送信号同时，就可以让信号传递一些附加信息。信号可以传递信息对程序开发是非常有意义的。

1. sa_mask指定在信号处理程序执行过程中，哪些信号应当被阻塞。缺省情况下当前信号本身被阻塞，防止信号的嵌套发送，除非指定SA_NODEFER或者SA_NOMASK标志位。

注：请注意sa_mask指定的信号阻塞的前提条件，是在由sigaction（）安装信号的处理函数执行过程中由sa_mask指定的信号才被阻塞。

1. sa_flags中包含了许多标志位，包括刚刚提到的SA_NODEFER及SA_NOMASK标志位。另一个比较重要的标志位是SA_SIGINFO，当设定了该标志位时，表示信号附带的参数可以被传递到信号处理函数中，因此，应该为sigaction结构中的sa_sigaction指定处理函数，而不应该为sa_handler指定信号处理函数，否则，设置该标志变得毫无意义。即使为sa_sigaction指定了信号处理函数，如果不设置SA_SIGINFO，信号处理函数同样不能得到信号传递过来的数据，在信号处理函数中对这些信息的访问都将导致段错误（Segmentation fault）。

信号的发送

发送信号的主要函数有：kill()、raise()、 sigqueue()、alarm()、setitimer()以及abort()。

kill()

1
2
3

#include <sys/types.h>
#include <signal.h>
int kill(pid_t pid,int signo)

该系统调用可以用来向任何进程或进程组发送任何信号。参数pid的值为信号的接收进程

• pid>0 进程ID为pid的进程
• pid=0 同一个进程组的进程
• pid<0 pid!=-1 进程组ID为 -pid的所有进程
• pid=-1 除发送进程自身外，所有进程ID大于1的进程

Sinno是信号值，当为0时（即空信号），实际不发送任何信号，但照常进行错误检查，因此，可用于检查目标进程是否存在，以及当前进程是否具有向目标发送信号的权限（root权限的进程可以向任何进程发送信号，非root权限的进程只能向属于同一个session或者同一个用户的进程发送信号）。

Kill()最常用于pid>0时的信号发送。该调用执行成功时，返回值为0；错误时，返回-1，并设置相应的错误代码errno。下面是一些可能返回的错误代码：
-EINVAL：指定的信号sig无效。
-ESRCH：参数pid指定的进程或进程组不存在。注意，在进程表项中存在的进程，可能是一个还没有被wait收回，但已经终止执行的僵死进程。
-EPERM： 进程没有权力将这个信号发送到指定接收信号的进程。因为，一个进程被允许将信号发送到进程pid时，必须拥有root权力，或者是发出调用的进程的UID 或EUID与指定接收的进程的UID或保存用户ID（savedset-user-ID）相同。如果参数pid小于-1，即该信号发送给一个组，则该错误表示组中有成员进程不能接收该信号。

sigqueue()

1
2
3

#include <sys/types.h>
#include <signal.h>
int sigqueue(pid_t pid, int sig, const union sigval val)

调用成功返回 0；否则，返回 -1。

sigqueue()是比较新的发送信号系统调用，主要是针对实时信号提出的（当然也支持前32种），支持信号带有参数，与函数sigaction()配合使用。

sigqueue的第一个参数是指定接收信号的进程ID，第二个参数确定即将发送的信号，第三个参数是一个联合数据结构union sigval，指定了信号传递的参数，即通常所说的4字节值。

1
2
3
4

typedef union sigval {
    int  sival_int;
    void *sival_ptr;
}sigval_t;

sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号，而不能发送信号给一个进程组。如果signo=0，将会执行错误检查，但实际上不发送任何信号，0值信号可用于检查pid的有效性以及当前进程是否有权限向目标进程发送信号。

在调用sigqueue时，sigval_t指定的信息会拷贝到对应sig 注册的3参数信号处理函数的siginfo_t结构中，这样信号处理函数就可以处理这些信息了。由于sigqueue系统调用支持发送带参数信号，所以比kill()系统调用的功能要灵活和强大得多。

alarm（）

1
2

#include <unistd.h>
unsigned int alarm(unsigned int seconds)

系统调用alarm安排内核为调用进程在指定的seconds秒后发出一个SIGALRM的信号。如果指定的参数seconds为0，则不再发送 SIGALRM信号。后一次设定将取消前一次的设定。该调用返回值为上次定时调用到发送之间剩余的时间，或者因为没有前一次定时调用而返回0。

注意，在使用时，alarm只设定为发送一次信号，如果要多次发送，就要多次使用alarm调用。

setitimer（）

现在的系统中很多程序不再使用alarm调用，而是使用setitimer调用来设置定时器，用getitimer来得到定时器的状态，这两个调用的声明格式如下：

1
2

int getitimer(int which, struct itimerval *value);
int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue);

1

#include <sys/time.h>

TIMER_REAL：按实际时间计时，计时到达将给进程发送SIGALRM信号。

ITIMER_VIRTUAL：仅当进程执行时才进行计时。计时到达将发送SIGVTALRM信号给进程。

ITIMER_PROF：当进程执行时和系统为该进程执行动作时都计时。与ITIMER_VIR-TUAL是一对，该定时器经常用来统计进程在用户态和内核态花费的时间。计时到达将发送SIGPROF信号给进程。

定时器中的参数value用来指明定时器的时间，其结构如下：

1
2
3
4

struct itimerval {
        struct timeval it_interval; /* 下一次的取值 */
        struct timeval it_value; /* 本次的设定值 */
};

1
2
3
4

struct timeval {
        long tv_sec; /* 秒 */
        long tv_usec; /* 微秒，1秒 = 1000000 微秒*/
};

在setitimer 调用中，参数ovalue如果不为空，则其中保留的是上次调用设定的值。定时器将it_value递减到0时，产生一个信号，并将it_value的值设定为it_interval的值，然后重新开始计时，如此往复。当it_value设定为0时，计时器停止，或者当它计时到期，而it_interval 为0时停止。调用成功时，返回0；错误时，返回-1，并设置相应的错误代码errno：

EFAULT：参数value或ovalue是无效的指针。

EINVAL：参数which不是ITIMER_REAL、ITIMER_VIRT或ITIMER_PROF中的一个。

下面是关于setitimer调用的一个简单示范，在该例子中，每隔一秒发出一个SIGALRM，每隔0.5秒发出一个SIGVTALRM信号：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#include <signal.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/time.h>
int sec;
void sigroutine(int signo) {
        switch (signo) {
        case SIGALRM:
        printf("Catch a signal -- SIGALRM ");
        break;
        case SIGVTALRM:
        printf("Catch a signal -- SIGVTALRM ");
        break;
        }
        return;
}
int main()
{
        struct itimerval value,ovalue,value2;
        sec = 5;
        printf("process id is %d ",getpid());
        signal(SIGALRM, sigroutine);
        signal(SIGVTALRM, sigroutine);
        value.it_value.tv_sec = 1;
        value.it_value.tv_usec = 0;
        value.it_interval.tv_sec = 1;
        value.it_interval.tv_usec = 0;
        setitimer(ITIMER_REAL, &value, &ovalue);
        value2.it_value.tv_sec = 0;
        value2.it_value.tv_usec = 500000;
        value2.it_interval.tv_sec = 0;
        value2.it_interval.tv_usec = 500000;
        setitimer(ITIMER_VIRTUAL, &value2, &ovalue);
        for (;;) ;
}

该例子的屏幕拷贝如下：

1
2
3
4
5
6
7
8

localhost:~$ ./timer_test
process id is 579
Catch a signal – SIGVTALRM
Catch a signal – SIGALRM
Catch a signal – SIGVTALRM
Catch a signal – SIGVTALRM
Catch a signal – SIGALRM
Catch a signal –GVTALRM

abort()

1
2

#include <stdlib.h>
void abort(void);

向进程发送SIGABORT信号，默认情况下进程会异常退出，当然可定义自己的信号处理函数。即使SIGABORT被进程设置为阻塞信号，调用abort()后，SIGABORT仍然能被进程接收。该函数无返回值。

raise()

1
2

#include <signal.h>
int raise(int signo)

向进程本身发送信号，参数为即将发送的信号值。调用成功返回 0；否则，返回 -1。

信号集及信号集操作函数：

信号集被定义为一种数据类型：

1
2
3

typedef struct {
    unsigned long sig[_NSIG_WORDS]；
} sigset_t

1
2
3
4
5
6
7
8
9
10
11

#include <signal.h>
int sigemptyset(sigset_t *set)；
int sigfillset(sigset_t *set)；
int sigaddset(sigset_t *set, int signum)
int sigdelset(sigset_t *set, int signum)；
int sigismember(const sigset_t *set, int signum)；
sigemptyset(sigset_t *set)初始化由set指定的信号集，信号集里面的所有信号被清空；
sigfillset(sigset_t *set)调用该函数后，set指向的信号集中将包含linux支持的64种信号；
sigaddset(sigset_t *set, int signum)在set指向的信号集中加入signum信号；
sigdelset(sigset_t *set, int signum)在set指向的信号集中删除signum信号；
sigismember(const sigset_t *set, int signum)判定信号signum是否在set指向的信号集中。

信号阻塞与信号未决

每个进程都有一个用来描述哪些信号递送到进程时将被阻塞的信号集，该信号集中的所有信号在递送到进程后都将被阻塞。下面是与信号阻塞相关的几个函数：

1
2
3
4

#include <signal.h>
int  sigprocmask(int  how,  const  sigset_t *set, sigset_t *oldset))；
int sigpending(sigset_t *set));
int sigsuspend(const sigset_t *mask))；

sigprocmask()函数能够根据参数how来实现对信号集的操作，操作主要有三种：

• SIG_BLOCK 在进程当前阻塞信号集中添加set指向信号集中的信号
• SIG_UNBLOCK 如果进程阻塞信号集中包含set指向信号集中的信号，则解除对该信号的阻塞
• SIG_SETMASK 更新进程阻塞信号集为set指向的信号集

sigpending(sigset_t *set))获得当前已递送到进程，却被阻塞的所有信号，在set指向的信号集中返回结果。

sigsuspend(const sigset_t *mask))用于在接收到某个信号之前, 临时用mask替换进程的信号掩码, 并暂停进程执行，直到收到信号为止。sigsuspend 返回后将恢复调用之前的信号掩码。信号处理函数完成后，进程将继续执行。该系统调用始终返回-1，并将errno设置为EINTR。

信号应用实例

linux下的信号应用并没有想象的那么恐怖，程序员所要做的最多只有三件事情：

• 安装信号（推荐使用sigaction()）；
• 实现三参数信号处理函数，handler(int signal,struct siginfo info, void )；
• 发送信号，推荐使用sigqueue()。

实际上，对有些信号来说，只要安装信号就足够了（信号处理方式采用缺省或忽略）。其他可能要做的无非是与信号集相关的几种操作。

实例一：信号发送及处理

实现一个信号接收程序sigreceive（其中信号安装由sigaction（））。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
void new_op(int,siginfo_t*,void*);
int main(int argc,char**argv)
{
    struct sigaction act;  
    int sig;
    sig=atoi(argv[1]);
    
    sigemptyset(&act.sa_mask);
    act.sa_flags=SA_SIGINFO;
    act.sa_sigaction=new_op;
    
    if(sigaction(sig,&act,NULL) < 0)
    {
            printf("install sigal error\n");
    }
    
    while(1)
    {
            sleep(2);
            printf("wait for the signal\n");
    }
}
 
void new_op(int signum,siginfo_t *info,void *myact)
{
        printf("receive signal %d", signum);
        sleep(5);
}

实例二：信号传递附加信息

主要包括两个实例：

向进程本身发送信号，并传递指针参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
void new_op(int,siginfo_t*,void*);
int main(int argc,char**argv)
{
        struct sigaction act;  
        union sigval mysigval;
        int i;
        int sig;
        pid_t pid;         
        char data[10];
        memset(data,0,sizeof(data));
        for(i=0;i < 5;i++)
                data[i]='2';
        mysigval.sival_ptr=data;

        sig=atoi(argv[1]);
        pid=getpid();
       
        sigemptyset(&act.sa_mask);
        act.sa_sigaction=new_op;//三参数信号处理函数
        act.sa_flags=SA_SIGINFO;//信息传递开关，允许传说参数信息给new_op
        if(sigaction(sig,&act,NULL) < 0)
        {
                printf("install sigal error\n");
        }
        while(1)
        {
                sleep(2);
                printf("wait for the signal\n");
                sigqueue(pid,sig,mysigval);//向本进程发送信号，并传递附加信息
        }
}

void new_op(int signum,siginfo_t *info,void *myact)//三参数信号处理函数的实现
{
        int i;
        for(i=0;i<10;i++)
        {
                printf("%c\n ",(*( (char*)((*info).si_ptr)+i)));
        }

       printf("handle signal %d over;",signum);
}

不同进程间传递整型参数：

把1中的信号发送和接收放在两个程序中，并且在发送过程中传递整型参数。

信号接收程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
void new_op(int,siginfo_t*,void*);
int main(int argc,char**argv)
{
        struct sigaction act;
        int sig;
        pid_t pid;         
       
        pid=getpid();
        sig=atoi(argv[1]);     
       
        sigemptyset(&act.sa_mask);
        act.sa_sigaction=new_op;
        act.sa_flags=SA_SIGINFO;
        if(sigaction(sig,&act,NULL)<0)

       {
                printf("install sigal error\n");
        }
        while(1)
        {
                sleep(2);
                printf("wait for the signal\n");
        }
}
void new_op(int signum,siginfo_t *info,void *myact)
{
        printf("the int value is %d \n",info->si_int);
}

信号发送程序：
命令行第二个参数为信号值，第三个参数为接收进程ID。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#include <signal.h>
#include <sys/time.h>
#include <unistd.h>
#include <sys/types.h>
main(int argc,char**argv)
{
        pid_t pid;
        int signum;
        union sigval mysigval;
        signum=atoi(argv[1]);
        pid=(pid_t)atoi(argv[2]);
        mysigval.sival_int=8;//不代表具体含义，只用于说明问题
        if(sigqueue(pid,signum,mysigval)==-1)
                printf("send error\n");
        sleep(2);
}

注：实例2的两个例子侧重点在于用信号来传递信息，目前关于在linux下通过信号传递信息的实例非常少，倒是Unix下有一些，但传递的基本上都是关于传递一个整数

实例三：信号阻塞及信号集操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#include "signal.h"
#include "unistd.h"
static void my_op(int);
main()
{
    sigset_t new_mask,old_mask,pending_mask;
    struct sigaction act;
    sigemptyset(&act.sa_mask);
    act.sa_flags=SA_SIGINFO;

    act.sa_sigaction=(void*)my_op;
    if(sigaction(SIGRTMIN+10,&act,NULL))
            printf("install signal SIGRTMIN+10 error\n");
    sigemptyset(&new_mask);
    sigaddset(&new_mask,SIGRTMIN+10);
    if(sigprocmask(SIG_BLOCK, &new_mask,&old_mask))
            printf("block signal SIGRTMIN+10 error\n");
    sleep(10);
    printf("now begin to get pending mask and unblock SIGRTMIN+10\n");

    if(sigpending(&pending_mask)<0)
            printf("get pending mask error\n");
    if(sigismember(&pending_mask,SIGRTMIN+10))
            printf("signal SIGRTMIN+10 is pending\n");
    if(sigprocmask(SIG_SETMASK,&old_mask,NULL)<0)
            printf("unblock signal error\n");
    printf("signal unblocked\n");
    sleep(10);
}

static void my_op(int signum)
{
        printf("receive signal %d \n",signum);
}

编译该程序，并以后台方式运行。在另一终端向该进程发送信号(运行kill -s 42 pid，SIGRTMIN+10为42)，查看结果可以看出几个关键函数的运行机制，信号集相关操作比较简单。

总结

一旦有信号产生，用户进程对信号产生的相应有三种方式：

1. 执行默认操作，linux对每种信号都规定了默认操作。
2. 捕捉信号，定义信号处理函数，当信号发生时，执行相应的处理函数。
3. 忽略信号，当不希望接收到的信号对进程的执行产生影响，而让进程继续执行时，可以忽略该信号，即不对信号进程作任何处理。

有两个信号是应用进程无法捕捉和忽略的，即SIGKILL和SEGSTOP，这是为了使系统管理员能在任何时候中断或结束某一特定的进程。

上图表示了Linux中常见的命令

信号发送：

信号发送的关键使得系统知道向哪个进程发送信号以及发送什么信号。下面是信号操作中常用的函数：

例子：创建子进程，为了使子进程不在父进程发出信号前结束，子进程中使用raise函数发送sigstop信号，使自己暂停；父进程使用信号操作的kill函数，向子进程发送sigkill信号，子进程收到此信号，结束子进程。

信号处理

当某个信号被发送到一个正在运行的进程时，该进程即对次特定的信号注册相应的信号处理函数，以完成所需处理。设置信号处理方式的是signal函数，在程序正常结束前，在应用signal函数恢复系统对信号的默认处理方式。

信号阻塞

有时候既不希望进程在接收到信号时立刻中断进程的执行，也不希望此信号完全被忽略掉，而是希望延迟一段时间再去调用信号处理函数，这个时候就需要信号阻塞来完成。

例子：主程序阻塞了cltr+c的sigint信号。用sigpromask将sigint假如阻塞信号集合。

管道：

管道允许在进程之间按先进先出的方式传送数据，是进程间通信的一种常见方式。

管道是Linux 支持的最初Unix IPC形式之一，具有以下特点：

1. 管道是半双工的，数据只能向一个方向流动；需要双方通信时，需要建立起两个管道；
2. 匿名管道只能用于父子进程或者兄弟进程之间（具有亲缘关系的进程）；
3. 单独构成一种独立的文件系统：管道对于管道两端的进程而言，就是一个文件，但它不是普通的文件，它不属于某种文件系统，而是自立门户，单独构成一种文件系统，并且只存在与内存中。

管道分为pipe（无名管道）和fifo（命名管道）两种，除了建立、打开、删除的方式不同外，这两种管道几乎是一样的。他们都是通过内核缓冲区实现数据传输。

pipe用于相关进程之间的通信，例如父进程和子进程，它通过pipe()系统调用来创建并打开，当最后一个使用它的进程关闭对他的引用时，pipe将自动撤销。

FIFO即命名管道，在磁盘上有对应的节点，但没有数据块——换言之，只是拥有一个名字和相应的访问权限，通过mknode()系统调用或者mkfifo()函数来建立的。一旦建立，任何进程都可以通过文件名将其打开和进行读写，而不局限于父子进程，当然前提是进程对FIFO有适当的访问权。当不再被进程使用时，FIFO在内存中释放，但磁盘节点仍然存在。

管道的实质是一个内核缓冲区，进程以先进先出的方式从缓冲区存取数据：管道一端的进程顺序地将进程数据写入缓冲区，另一端的进程则顺序地读取数据，该缓冲区可以看做一个循环队列，读和写的位置都是自动增加的，一个数据只能被读一次，读出以后再缓冲区都不复存在了。当缓冲区读空或者写满时，有一定的规则控制相应的读进程或写进程是否进入等待队列，当空的缓冲区有新数据写入或慢的缓冲区有数据读出时，就唤醒等待队列中的进程继续读写。

管道的作用是在具有亲缘关系的进程之间传递消息，所谓有亲缘关系，是指有同一个祖先。所以管道并不是只可以用于父子进程通信，也可以在兄弟进程之间还可以用在祖孙之间等，反正只要共同的祖先调用了pipe函数，打开的管道文件就会在fork之后，被各个后代所共享。
不过由于管道是字节流通信，没有消息边界，多个进程同时发送的字节流混在一起，则无法分辨消息，所有管道一般用于2个进程之间通信，另外管道的内容读完后不会保存，管道是单向的，一边要么读，一边要么写，不可以又读又写，想要一边读一边写，那就创建2个管道，如下图

管道是一种文件，可以调用read、write和close等操作文件的接口来操作管道。另一方面管道又不是一种普通的文件，它属于一种独特的文件系统：pipefs。管道的本质是内核维护了一块缓冲区与管道文件相关联，对管道文件的操作，被内核转换成对这块缓冲区内存的操作。下面我们来看一下如何使用管道。

1
2

#include<unistd.h>
int pipe(int fd[2])

成功调用pipe函数之后，可以对写入端描述符pipefd[1]调用write，向管道里面写入数据，代码如下所示：

1

write(pipefd[1],wbuf,count);

无名管道：

pipe的例子：父进程创建管道，并在管道中写入数据，而子进程从管道读出数据

命名管道：

和无名管道的主要区别在于，命名管道有一个名字，命名管道的名字对应于一个磁盘索引节点，有了这个文件名，任何进程有相应的权限都可以对它进行访问。

而无名管道却不同，进程只能访问自己或祖先创建的管道，而不能访任意访问已经存在的管道——因为没有名字。

Linux中通过系统调用mknod()或makefifo()来创建一个命名管道。最简单的方式是通过直接使用shell

1

mkfifo myfifo

1

mknod myfifo p

使用open()函数通过文件名可以打开已经创建的命名管道，而无名管道不能由open来打开。当一个命名管道不再被任何进程打开时，它没有消失，还可以再次被打开，就像打开一个磁盘文件一样。

可以用删除普通文件的方法将其删除，实际删除的事磁盘上对应的节点信息。

例子：用命名管道实现聊天程序，一个张三端，一个李四端。两个程序都建立两个命名管道，fifo1,fifo2,张三写fifo1，李四读fifo1；李四写fifo2，张三读fifo2。

用select把管道描述符和stdin加入集合，用select进行阻塞，如果有i/o的时候唤醒进程。（粉红色部分为select部分，黄色部分为命名管道部分）

在linux系统中，除了用pipe系统调用建立管道外，还可以使用C函数库中管道函数popen函数来建立管道，使用pclose关闭管道。

例子：设计一个程序用popen创建管道，实现 ls -l |grep main.c的功能

分析：先用popen函数创建一个读管道，调用fread函数将ls -l的结果存入buf变量，用printf函数输出内容，用pclose关闭读管道；

接着用popen函数创建一个写管道，调用fprintf函数将buf的内容写入管道，运行grep命令。

popen的函数原型：

1

FILE* popen(const char* command,const char* type);

使用popen函数读写管道，实际上也是调用pipe函数调用建立一个管道，再调用fork函数建立子进程，接着会建立一个shell 环境，并在这个shell环境中执行参数所指定的进程。

消息队列：

消息队列，就是一个消息的链表，是一系列保存在内核中消息的列表。用户进程可以向消息队列添加消息，也可以向消息队列读取消息。

消息队列与管道通信相比，其优势是对每个消息指定特定的消息类型，接收的时候不需要按照队列次序，而是可以根据自定义条件接收特定类型的消息。

可以把消息看做一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息，对消息队列有读权限的进程可以从消息队列中读取消息。

消息队列的常用函数如下表：

进程间通过消息队列通信，主要是：创建或打开消息队列，添加消息，读取消息和控制消息队列。

例子：用函数msget创建消息队列，调用msgsnd函数，把输入的字符串添加到消息队列中，然后调用msgrcv函数，读取消息队列中的消息并打印输出，最后再调用msgctl函数，删除系统内核中的消息队列。（黄色部分是消息队列相关的关键代码，粉色部分是读取stdin的关键代码）

消息队列可以认为是一个链表。进程（线程）可以往里写消息，也可以从里面取出消息。一个进程可以往某个消息队列里写消息，然后终止，另一个进程随时可以从消息队列里取走这些消息。这里也说明了，消息队列具有随内核的持续性，也就是系统不重启，消息队列永久存在。

创建（并打开）、关闭、删除一个消息队列

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#include <stdio.h>  
#include <stdlib.h> 
#include <mqueue.h>   //头文件
#include <sys/types.h>  
#include <sys/stat.h>  
#include <unistd.h>  
#include <fcntl.h>  
#include <errno.h>   

#define MQ_NAME ("/tmp")  
#define MQ_FLAG (O_RDWR | O_CREAT | O_EXCL) // 创建MQ的flag  
#define FILE_MODE (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) // 设定创建MQ的权限  

int main()  

{  
    mqd_t posixmq;  
    int rc = 0;  

    /*  
    函数说明：函数创建或打开一个消息队列  
    返回值：成功返回消息队列描述符，失败返回-1，错误原因存于errno中  
    */ 
    posixmq = mq_open(MQ_NAME, MQ_FLAG, FILE_MODE, NULL);  

    if(-1 == posixmq)  
    {  
        perror("创建MQ失败");  
        exit(1);  
    }  

    /*  
    函数说明：关闭一个打开的消息队列，表示本进程不再对该消息队列读写  
    返回值：成功返回0，失败返回-1，错误原因存于errno中  
    */ 
    rc = mq_close(posixmq);  
    if(0 != rc)  
    {  
        perror("关闭失败");  
        exit(1);  
    }  

    /*  
    函数说明：删除一个消息队列，好比删除一个文件，其他进程再也无法访问  
    返回值：成功返回0，失败返回-1，错误原因存于errno中  
    */
    rc = mq_unlink(MQ_NAME);  
    if(0 != rc)  
    {  
        perror("删除失败");  
        exit(1);  
    }  

    return 0;  
} 

1
2
3
4
5
6

root@linux:/mnt/hgfs/C_libary# gcc -o crtmq crtmq.c
/tmp/ccZ9cTxo.o: In function `main':
crtmq.c:(.text+0x31): undefined reference to `mq_open'
crtmq.c:(.text+0x60): undefined reference to `mq_close'
crtmq.c:(.text+0x8f): undefined reference to `mq_unlink'
collect2: ld returned 1 exit status

1
2

root@linux:/mnt/hgfs/C_libary# gcc -o crtmq crtmq.c -lrt
root@linux:/mnt/hgfs/C_libary# ./crtmq

1
2

root@linux:/mnt/hgfs/C_libary# ./crtmq 
创建MQ失败: File  exit(0)

1. 消息队列的名字最好使用“/”打头，并且只有一个“/”的名字。否则可能出现移植性问题；（还需保证在根目录有写权限,为了方便我在root权限下测试）
2. 创建成功的消息队列不一定能看到，使用一些方法也可以看到，本文不做介绍；

消息队列的名字有如此规定，引用《UNIX网络编程 卷2》的相关描述： mq_open,sem_open,shm_open这三个函数的第一个参数是
一个IPC名字，它可能是某个文件系统中的一个真正存在的路径名，也可能不是。Posix.1是这样描述Posix IPC名字的。

1. 它必须符合已有的路径名规则（最多由PATH_MAX个字节构成，包括结尾的空字节）
2. 如果它以斜杠开头，那么对这些函数的不同调用将访问同一个队列，否则效果取决于实现（也就是效果没有标准化）
3. 名字中的额外的斜杠符的解释由实现定义（同样是没有标准化） 因此，为便于移植起见，Posix IPC名字必须以一个斜杠打头，并且不能再包含任何其他斜杠符。

IPC通信:Posix消息队列读,写
创建消息队列的程序:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

#include <stdio.h>  
#include <stdlib.h> 
#include <mqueue.h>   //头文件
#include <sys/types.h>  
#include <sys/stat.h>  
#include <unistd.h>  
#include <fcntl.h>  
#include <errno.h>   

#define MQ_NAME ("/tmp")  
#define MQ_FLAG (O_RDWR | O_CREAT | O_EXCL) // 创建MQ的flag  
#define FILE_MODE (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) // 设定创建MQ的权限  

int main()  

{  
    mqd_t posixmq;  
    int rc = 0;  

    /*  
    函数说明：函数创建或打开一个消息队列  
    返回值：成功返回消息队列描述符，失败返回-1，错误原因存于errno中  
    */ 
    posixmq = mq_open(MQ_NAME, MQ_FLAG, FILE_MODE, NULL);  

    if(-1 == posixmq)  
    {  
        perror("创建MQ失败");  
        exit(1);  
    }  

    /*  
    函数说明：关闭一个打开的消息队列，表示本进程不再对该消息队列读写  
    返回值：成功返回0，失败返回-1，错误原因存于errno中  
    */ 
    rc = mq_close(posixmq);  
    if(0 != rc)  
    {  
        perror("关闭失败");  
        exit(1);  
    }  

#if 0
    /*  
    函数说明：删除一个消息队列，好比删除一个文件，其他进程再也无法访问  
    返回值：成功返回0，失败返回-1，错误原因存于errno中  
    */
    rc = mq_unlink(MQ_NAME);  
    if(0 != rc)  
    {  
        perror("删除失败");  
        exit(1);  
    }  

    return 0;
#endif  
} 

1
2

root@linux:/mnt/hgfs/C_libary# gcc -o crtmq crtmq.c -lrt
root@linux:/mnt/hgfs/C_libary# ./crtmq

1
2

root@linux:/mnt/hgfs/C_libary# ./crtmq 
创建MQ失败: File  exit(0)

消息队列的读写主要使用下面两个函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/*头文件*/
#include <mqueue.h>  

/*返回：若成功则为消息中字节数，若出错则为-1 */ 
int mq_send(mqd_t mqdes, const char *msg_ptr, size_t msg_len, unsigned msg_prio); 

/*返回：若成功则为0， 若出错则为-1*/ 
ssize_t mq_receive(mqd_t mqdes, char *msg_ptr, size_t msg_len, unsigned *msg_prio);  

/*消息队列属性结构体*/
struct mq_attr { 
   long mq_flags;       /* Flags: 0 or O_NONBLOCK */ 
   long mq_maxmsg;      /* Max. # of messages on queue */ 
   long mq_msgsize;     /* Max. message size (bytes) */ 
   long mq_curmsgs;     /* # of messages currently in queue */ 
};

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

#include <stdio.h>  
#include <stdlib.h>  
#include <mqueue.h>  
#include <sys/types.h>  
#include <sys/stat.h>  
#include <unistd.h>  
#include <fcntl.h>  
#include <errno.h>  
   
/*向消息队列发送消息，消息队列名及发送的信息通过参数传递*/ 
int main(int argc, char *argv[])  
{  
    mqd_t mqd;  
    char *ptr;  
    size_t len;  
    unsigned int prio;  
    int rc;  

    if(argc != 4)  
    {  
        printf("Usage: sendmq <name> <bytes> <priority>\n");  
        exit(1);  
    }  

    len = atoi(argv[2]);  
    prio = atoi(argv[3]);    

    //只写模式找开消息队列  
    mqd = mq_open(argv[1], O_WRONLY);  
    if(-1 == mqd)  
    {  
        perror("打开消息队列失败");  
        exit(1);  
    }  

    // 动态申请一块内存  
    ptr = (char *) calloc(len, sizeof(char));  
    if(NULL == ptr)  
    {  
        perror("申请内存失败");  
        mq_close(mqd);  
        exit(1);  
    }  
   
    /*向消息队列写入消息，如消息队列满则阻塞，直到消息队列有空闲时再写入*/ 
    rc = mq_send(mqd, ptr, len, prio);  
    if(rc < 0)  
    {  
        perror("写入消息队列失败");  
        mq_close(mqd);  
        exit(1);  
    }     

    // 释放内存  
    free(ptr);  
    return 0;  
} 

1
2
3
4
5

root@linux:/mnt/hgfs/C_libary# gcc -o sendmq sendmq.c -lrt
root@linux:/mnt/hgfs/C_libary# ./sendmq /tmp 30 15
root@linux:/mnt/hgfs/C_libary# ./sendmq /tmp 30 16
root@linux:/mnt/hgfs/C_libary# ./sendmq /tmp 30 17
root@linux:/mnt/hgfs/C_libary# ./sendmq /tmp 30 18

读消息队列：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63