adoryn个人页面-阿里云开发者社区

Java并发编程：Java内存模型

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zhaobryant/article/details/79602051 一、Java内存模型基础 1. 两个关键问题 2. Java内存模型的抽象结构 3. 指令序列的重排序 4. 并发编程模型的分类 5. happens-before 二、指令重排序 1. 数据依赖性 2. as-if-serial语义 3. 重排序对多线程的影响三、顺序一致性内存模型 1、数据竞争与顺序一致性 2、顺序一致性内存模型 3. 同步程序的顺序一致性效果四、volatile的内存语义 1、volatile的特性 2、volatile读写建立的happens-before关系 3、volatile写读的内存语义 4. volatile内存语义的实现 5. 为什么增强volatile的内存语义五、锁的内存语义 1、锁的释放获取所建立的happens-before关系 2、锁的释放和获取的内存语义 3、锁内存语义的实现 4、concurrent包的实现六、final域的内存语义七、happens-before 1、JMM的设计 2、happens-before的定义 3、happens-before规则八、双重检查锁定与延迟初始化 1、双重检查锁定 2、问题的根源 3、基于volatile的解决方案 4、基于类初始化的解决方案九、Java内存模型综述十、小结一、Java内存模型基础 1. 两个关键问题线程之间如何通信；线程之间如何同步。线程之间的通信机制：共享内存+消息传递。在共享内存的并发模型里，线程之间共享程序的公共状态，通过读写内存中的公共状态进行隐式通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过发送消息来显式进行通信。 Java并发采用的是共享内存模型，Java线程之间的通信总是隐式进行的。 2. Java内存模型的抽象结构 Java线程之间的通信由Java内存模型控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。 JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory），本地内存中存储了该线程以读写共享变量的副本。从上图可以看出，如果线程A和线程B之间要通信的话，必须要经历两个步骤：线程A把本地内存A中更新过的共享变量刷新到主内存中去；线程B到主内存中去读取线程A之前已经更新过的共享变量。从整体上看，上述两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为Java程序员提供内存可见性保证。 3. 指令序列的重排序为了提高性能，编译器和处理器常常会对指令进行重排序。重排序包括以下三种类型：编译器优化的重排序指令级并行的重排序——指令级并行技术。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。内存系统的重排序对于编译器重排序，JMM的编译器重排序规则会禁止特定类型的编译器重排序。对于处理器重排序，JMM的处理器重排序规则要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序。 4. 并发编程模型的分类处理器使用写缓冲区临时保存向内存写入的数据。示例：其内部执行过程如下所示：这里，处理器A和处理器B可以同时把共享变量写入自己的写缓冲区（A1，B1），然后从内存中读取另一个共享变量（A2，B2），最后才把自己写缓冲区中保存的脏数据刷新到内存中（A3，B3）。当以这种时序执行时，程序就可以得到x=y=0的结果。为了保证内存可见性，Java编译器在生成指令序列的适当位置插入内存屏障指令来禁止特定类型的处理器重排序。JMM的内存屏障指令分为以下4类： 5. happens-before Java JSR-133使用happens-before概念来阐述操作之间的内存可见性。与程序员密切相关的happens-before规则如下：程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。 volatile变量规则：对一个volatile变量的写，happens-before于任意后续对这个volatile变量的读。传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。 happens-before与JMM的关系：二、指令重排序重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段。 1. 数据依赖性如果两个操作访问同一个变量，且这两个操作中有一个写操作，此时这两个操作之间就存在数据依赖性。对于数据依赖性，主要分为三种类型：对于上述三种情况，只要重排序两个操作的操作顺序，程序的执行结果就会被改变。 2. as-if-serial语义 as-if-serial语义的意思是：不管怎么重排序，单线程程序的执行结果不能被改变。为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。例如： double pi = 3.14; //A double r = 1.0; //B double area = pi * r * r; //C 对于上述操作的数据依赖关系，如下所示：其存在两种执行顺序，如下所示： as-if-serial语义使单线程程序员无需担心重排序是否会干扰到其正常运行，也无需担心内存可见性问题。 3. 重排序对多线程的影响示例代码： class RecordExample { int a = 0; boolean flag = false; public void writer() { a = 1; //1 flag = true; //2 } public void reader() { if (flag) { //3 int i = a * a; //4 } } } 可能的程序执行时序图如下：三、顺序一致性内存模型顺序一致性内存模型是一个理论参考模型，在设计的时候，处理器的内存模型和编程语言的内存模型都会以顺序一致性内存模型作为参考。 1、数据竞争与顺序一致性 Java内存模型规范对数据竞争的定义如下：在一个线程写一个变量；在另一个线程读同一个变量；读和写没有通过同步来排序。当代码中包含数据竞争时，程序的执行往往产生违反直觉的结果。如果一个多线程程序能正确同步，这个程序将是一个没有数据竞争的程序。顺序一致性（Sequentially Consistent）——程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同。 2、顺序一致性内存模型顺序一致性内存模型有两大特性：一个线程中的所有操作必须按照程序的顺序来执行；所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。顺序一致性内存模型为程序员提供的视图：当多个线程并发执行时，上图的开关装置能把所有线程的所有内存读写操作串行化，即在顺序一致性模型中，所有操作之间具有全序关系。举例说明：A和B两个线程。一种执行过程（同步）：另一种执行过程（非同步）： 3. 同步程序的顺序一致性效果示例程序： class SynchronizeExample { int a = 0; boolean flag = false; public synchronized void writer() { // 获取锁 a = 1; flag = true; } // 释放锁 public synchronized void reader() { // 获取锁 if (flag) { int i = a; //... } } // 释放锁 } 两个内存模型中的执行顺序： JMM在具体实现上的基本方针：在不改变（正确同步的）程序执行结果的前提下，尽可能地为编译器和处理器的优化打开方便之门。未同步程序在两个模型中的执行特性存在如下几个差异：顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行（重排序）。顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。 JMM不保证对64位的long型和double型变量的写操作具有原子性，而顺序一致性模型保证对所有的内存读写操作具有原子性。总线仲裁 –> 总线事务！！！四、volatile的内存语义 1、volatile的特性 volatile变量具有以下特性：可见性。原子性。对任意单个volatile变量的读写具有原子性，但类似volatile++这种复合操作不具有原子性。 2、volatile读写建立的happens-before关系 volatile对于线程的内存可见性的影响比volatile自身的特性更为重要。从内存语义上来说，volatile的写读与锁的释放获取有相同的内存效果。请看下面使用volatile变量的示例代码： class VolatileExample { int a = 0; volatile boolean flag = false; public void writer() { a = 1; //1 flag = true; //2 } public void reader() { if (flag) { //3 int i = a; //4 ... } } } 假设线程A执行writer()方法之后，线程B执行reader()方法。根据happens-before规则，该过程建立的happens-before关系可以分为3类：根据程序次序规则：1 happens-before 2; 3 happens-before 4。根据volatile规则：2 happens-before 3。根据happens-before的传递性规则：1 happens-before 4。因此，上述关系的图形化表现形式如下：在上图中，每一个箭头链接的两个节点，代表了一个happens-before关系。黑色箭头表示程序顺序规则；橙色箭头表示volatile规则；蓝色箭头表示组合这些规则后提供的happens-before保证。 3、volatile写读的内存语义 volatile写的内存语义如下：当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。 volatile读的内存语义如下：当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效。线程接下来将从主内存中读取共享变量。总结一下：线程A写一个volatile变量，实质上是线程A向接下来将要读这个volatile变量的某个线程发出了其对共享变量所做修改的消息。线程B读一个volatile变量，实质上是线程B接收了之前某个线程发出的在写这个volatile变量之前对共享变量所做修改的消息。线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A通过主内存向线程B发送消息。 4. volatile内存语义的实现为了实现volatile内存语义，JMM会限制编译器重排序和处理器重排序。规则表：从上表，我们可以看出：当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。其确保了volatile写之前的操作不会被编译器重排序到volatile写之后。当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。其确保了volatile读之后的操作不会被编译器重排序到volatile读之前。当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。实现方式：内存屏障。具体内存屏障插入策略如下：在每个volatile写操作前插入一个StoreStore屏障。在每个volatile写操作后插入一个StoreLoad屏障。在每个volatile读操作后插入一个LoadLoad屏障。在每个volatile读操作后插入一个LoadStore屏障。保守策略下，volatile写插入内存屏障后生成的指令序列示意图： StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主内存。volatile写之后的StoreLoad屏障的作用是避免volatile写与后面可能有的volatile读写操作重排序（保守策略）。保守策略下，volatile读插入内存屏障后生成的指令序列示意图： LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。举一个例子： class VolatileBarrierExample { int a; volatile int v1 = 1; volatile int v2 = 2; void readAndWrite() { int i = v1; // 第一个volatile读 int j = v2; // 第二个volatile读 a = i + j; // 普通写 v1 = i + 1; // 第一个volatile写 v2 = j * 2; // 第二个volatile写 } ... //写 } 对应的指令序列示意图如下： 5. 为什么增强volatile的内存语义 class VolatileExample { int a = 0; volatile boolean flag = false; public void writer() { a = 1; //1 flag = true; //2 } public void reader() { if (flag) { //3 int i = a; //4 ... } } } 在旧的内存模型中，可以使用指令重排序，因此，时序图如下所示：结果：读线程B执行4时，不一定能看到线程A在执行1时对共享变量的修改。 volatile内存语义增强： volatile严格限制编译器和处理器对volatile变量与普通变量的重排序，确保volatile的写读和锁的释放获取具有相同的内存语义。不过，要很好地利用volatile来完成锁机制下的并发过程，是十分困难的，一定要谨慎。五、锁的内存语义 1、锁的释放获取所建立的happens-before关系锁是Java并发编程中最重要的同步机制。示例： class MonitorExample { int a = 0; public synchronized void writer() { //1 a++; //2 } //3 public synchronized void reader() { //4 int i = a; //5 ... } //6 } 假设线程A执行writer()方法，随后线程B执行reader()方法。根据happens-before规则，该过程包含三类关系：程序次序规则：1 happens-before 2, 2 happens-before 3, 4 happens-before 5, 5 happens-before 6。监视器锁规则：3 happens-before 4。 happens-before的传递性：2 happens-before 5。示意图如下：在上图中，每一个箭头链接的两个节点，代表了一个happens-before关系。黑色箭头表示程序顺序规则；橙色箭头表示监视器锁规则；蓝色箭头表示组合这些规则后提供的happens-before保证。 2、锁的释放和获取的内存语义当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。当线程获取锁时，JMM会把该线程对应的本地内存设置为无效，从而使得被监视器保护的临界区代码必须从主内存中读取变量。总结一下：线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了线程A对共享变量所做修改的消息。线程B获取一个锁，实质上是线程B接收了之前某个线程发出的在释放这个锁之前对共享变量所做修改的消息。线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程b发送消息。 3、锁内存语义的实现在这里，我们借助ReentrantLock的源码，来分析锁内存语义的具体实现机制。示例代码： class ReentrantLockExample { int a = 0; ReentrantLock lock = new ReentrantLock(); public void writer() { lock.lock(); //获取锁 try { a++; } finally { lock.unlock(); //释放锁 } } public void reader() { lock.lock(); //获取锁 try { int i = a; ... } finally { lock.unlock(); //释放锁 } } } ReentrantLock的实现依赖于Java同步器框架AbstractQueuedSychronizer（AQS）。基本类图： ReentrantLock分为公平锁和非公平锁。公平锁的加锁过程： Step1: ReentrantLock.lock(); Step2: FairSync.lock(); Step3: AbstractQueuedSynchronizer.acquire(int arg); Step4: ReentrantLock.tryAcquire(int acquires); 第四步为核心，如下： protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); //获取锁的开始，首先读取volatile变量state if (c == 0) { if (isFirst(current) && compareAndSetState(0, acquires)) { return true; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) { throw new Error("Maximum lock count exceeded."); } setState(nextc); return true; } return false; } 核心：读取volatile变量state。公平锁的解锁过程： Step1: ReentrantLock.unlock(); Step2: AbstractQueuedSynchronizer.release(int arg); Step3: Sync.tryRelease(int releases); 第三步为核心，如下： protected final boolean tryRelease(int releases) { int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) { throw new IllegalMonitorStateException(); } boolean free = false; if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); //释放锁的最后，写volatile变量state return free; } 公平锁在释放锁的最后写volatile变量state，在获取锁时首先读这个volatile变量。根据volatile的happens-before规则，释放锁的线程在写volatile变量之前可见的共享变量，在获取锁的线程读取同一个volatile变量后将立即变得对获取锁的线程可见。 4、concurrent包的实现 Java线程之间的通信方式： A线程写volatile变量，随后B线程读这个volatile变量。 A线程写volatile变量，随后B线程使用CAS更新这个volatile变量。 A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。 A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。六、final域的内存语义对于final域，编译器和处理器要遵守两个重排序规则：在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。七、happens-before happens-before是JMM最核心的概念。 1、JMM的设计在设计JMM时，需要考虑两个关键因素：程序员对内存模型的使用。程序员希望基于一个强内存模型来编写代码。编译器和处理器对内存模型的实现。编译器和处理器希望实现一个弱内存模型。由于上述两个因素的互相矛盾，因此需要找到一个好的平衡点：一方面，要为程序员提供足够强的内存可见性保证；另一方面，对编译器和处理器的限制要尽可能地放松。 JMM把happens-before要求禁止的重排序分为下面两类：会改变程序执行结果的重排序；不会改变程序执行结果的重排序。 JMM对于这两种不同性质的重排序，采取了不同的策略，如下：对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序。对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求。如下所示：如上所示，可以得出以下两点： JMM向程序员提供的happens-before规则能满足程序员的需求。 JMM对编译器和处理器的束缚已经尽可能少。基本原则：只要不改变程序的执行结果，编译器和处理器怎么优化都行。 2、happens-before的定义定义如下：如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。 —— JMM对程序员的承诺两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。只要结果一致，重排序就不非法。 —— JMM对编译器和处理器重排序的约束原则 3、happens-before规则程序次序规则：一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。锁定规则：这个规则比较好理解，无论是在单线程环境还是多线程环境，一个锁处于被锁定状态，那么必须先执行unlock操作后面才能进行lock操作。 volatile变量规则：这是一条比较重要的规则，它标志着volatile保证了线程可见性。通俗点讲就是如果一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作一定是happens-before读操作的。传递规则：提现了happens-before原则具有传递性，即A happens-before B , B happens-before C，那么A happens-before C。线程启动规则：假定线程A在执行过程中，通过执行ThreadB.start()来启动线程B，那么线程A对共享变量的修改在接下来线程B开始执行后确保对线程B可见。线程终结规则：假定线程A在执行的过程中，通过制定ThreadB.join()等待线程B终止，那么线程B在终止之前对共享变量的修改在线程A等待返回后可见。线程启动规则示例：线程终结规则示例：八、双重检查锁定与延迟初始化 1、双重检查锁定写一个线程安全的单例模式： public class DoubleCheckedLocking { //1 private static Instance instance; //2 public static Instance getInstance() { //3 if (instance == null) { //4：第一次检查 synchronized(DoubleCheckedLocking.class) { //5：加锁 if (instance == null) { //6：第二次检查 instance = new Instance(); //7：问题的根源 } //8 } //9 } //10 return instance; } } 问题：在线程执行到第四行，代码读取到instance不为null时，instance引用的对象有可能没有完成初始化。 2、问题的根源示例代码第7行instance = new Instance();创建对象，其可分解为： memory = allocate(); //1. 分配对象的内存空间 ctorInstance(memory); //2. 初始化对象 instance = memory; //3. 设置instance指向刚分配的内存地址上面2和3之间可能会被重排序。2和3之间重排序之后的执行时序（并不违反JMM规则）如下： memory = allocate(); //1. 分配对象的内存空间 instance = memory; //2. 设置instance指向刚分配的内存地址 // 注意：此时对象还未初始化 ctorInstance(memory); //3. 初始化对象上述过程多线程下并发执行的情况：单线程的执行时序图：多线程的执行时序图：所以对于上述多线程情况，可以知道，线程B访问目标对象时，目标对象并未进行初始化。此处就会出现问题。如何解决？两种方法：不允许2和3重排序；允许2和3重排序，但不允许其他线程看到这个重排序。 3、基于volatile的解决方案 public class SafeDoubleCheckedLocking { private volatile static Instance instance; public static Instance getInstance() { if (instance == null) { synchronized (SafeDoubleCheckedLocking.class) { if (instance == null) { instance = new Instance(); //instance为volatile，现在没有问题了 } } } } } 当声明对象的引用为volatile时，2和3之间的重排序在多线程环境中将会被禁止。 4、基于类初始化的解决方案 JVM在类的初始化阶段，会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁，这个锁可以同步多个线程多同一个类的初始化。 public class InstanceFactory { private static class InstanceHolder { public static Instance instance = new Instance(); } public static Instance getInstance() { return InstanceHolder.instance; //这里将触发InstancHolder类被初始化 } } 上述过程如下：该方案的实质是：允许2和3重排序，但不允许非构造线程看到这个重排序。附加：一个类或接口被初始化的5种情况： 1. T是一个类，而且一个T类型的实例被创建； 2. T是一个类，且T中声明的一个静态方法被调用； 3. T中声明的一个静态字段被赋值； 4. T中声明的一个静态字段被使用，而且这个字段不是一个常量字段； 5. T是一个顶级类，而且一个断言语句嵌套在T内部被执行。类初始化的处理过程的五个阶段：第一阶段：通过在Class对象上同步（即获取Class对象的初始化锁），来控制类或接口的初始化。这个获取锁的线程会一直等待，直到当前线程能够获取到这个初始化锁。第二阶段：线程A执行类的初始化，同时线程B在初始化锁对应的condition上等待。第三阶段：线程A设置state=initialized，然后唤醒在condition中等待的所有线程。第四阶段：线程B结束类的初始化处理。第五阶段：线程C执行类的初始化的处理。静态内部类的加载过程：静态内部类的加载不需要依附外部类，在使用时才加载。九、Java内存模型综述十、小结本文对Java内存模型做了比较全面的解读。

Docker技术剖析：Docker背后的内核知识

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zhaobryant/article/details/79599432 Docker本质上是运行在宿主机上的进程，它通过namespace实现了资源隔离，并通过cgroups实现了资源限制，同时通过写时复制（copy-on-write）实现了高效的文件操作。一、通过namespace实现资源隔离 Linux内核中提供了6种namespace隔离的系统调用，分别完成对文件系统、网络、进程间通信、主机名、进程号以及用户权限的隔离。具体如下所示： namespace 系统调用参数隔离内容 UTS CLONE_NEWUTS 主机名与域名 IPC CLONE_NEWIPC 信号量/消息队列/共享内存 PID CLONE_NEWPID 进程编号 Network CLONE_NEWNET 网络设备/网络栈/端口等 Mount CLONE_NEWNS 挂载点（文件系统） User CLONE_NEWUSER 用户和用户组 Linux内核实现namespace的主要目的之一就是实现轻量级虚拟化容器服务。在同一个namespace下的进程可以感知彼此的变化，而对外界的进程一无所知。这样就可以让容器中的进程产生错觉，仿佛置身于一个独立的系统环境中，从而达到独立和隔离的目的。 1. 进行namespace API操作的4种方式 namespace的API包括clone()、setns()、unshare()以及/proc下的部分文件。（1）通过clone()在创建新进程的同时创建namespace 对于clone()系统调用，其调用方式如下： int clone(int (*child_func)(void *), void *child_stack, int flags, void *args); clone()实际上是Linux系统调用fork()的一种更通用的实现方式，它可以通过flags来控制使用多少功能。 clone()标志位参数中与namespace相关的四个参数分别是： child_func：用于传入子进程运行的程序主函数； child_stack：用于传入子进程使用的栈空间； flags：表示使用哪些CLONE_*标志位，主要包括如上表所示的系统调用参数； args：表示可用于传入的用户参数。（2）通过setns()加入一个已经存在的namespace 对于setns()系统调用，其调用方式如下： int setns(int fd, int nstype); 通过setns()系统调用，进程可以从原来的namespace加入某个已存在的namespace中。 setns()系统调用中的参数如下： fd：表示要加入namespace的文件描述符。namespace实际上也是一个文件，有对应的文件描述符。它是一个指向/proc/[pid]/ns目录的文件描述符。 nstype：表示是否检查fd指向的namespace类型是否符合实际要求。该参数为0表示不检查。通常，为了不影响进程的调用者，也为了使新加入的pid namespace生效，会在setns()函数执行后使用clone()创建子进程继续执行命令，让原先的进程结束运行。例如，新创建namespace，并在该namespace中调用/bin/bash并接受参数，以运行shell。用法如下所示： fd = open(argv[1], O_RDONLY); // 获取namespace文件描述符 setns(fd, 0); // 加入新的namespace execvp(argv[2], &argv[2]); // 执行程序假设编译后的程序名称为setnsdemo，于是可以执行： $ ./setnsdemo /proc/27514/ns/uts /bin/bash # uts是对应进程号为27514的进程对应uts的namespace号至此，就可以在新加入的namespace中执行shell命令了。（3）通过unshare()在原先进程上进行namespace隔离对于unshare()系统调用，其调用方式： int unshare(int flags); 与clone()不同的是，unshare()运行在原来的进程上，不需要启动一个新进程。调用unshare()的主要作用是不启动一个新进程就可以起到隔离的效果，相当于跳出原先的namespace进行操作。（4）查看/proc/[pid]/ns文件从3.8版本的内核开始，用户就可以在/proc/[pid]/ns文件夹下看到指向不同namespace号的文件，如下图所示：注意：如果两个进程指向的namespace编号相同，就说明它们在同一个namespace之下，否则便在不同namespace中。那么为什么要在/proc/[pid]/ns中设置这些link链接呢？其一：用于记录[pid]所对应的进程的namespace信息，方便查阅；其二：一旦上述link文件被打开，只要打开的文件描述符存在，就算该namespace下的所有进程都已经结束，这个namespace也会一直存在，后续进程也可以再加入进来。在Docker中，通过文件描述符定位和加入一个存在的namespace是最基本的方式。 2. UTS namespace UTS（Unix Time-sharing System）namespace提供了主机名和域名的隔离，这样，每个Docker容器就可以拥有独立的主机名和域名了，在网络上可以被当作一个独立的节点，而非宿主机上的一个进程，其标志位为CLONE_NEWUTS。在Docker中，每个镜像基本都以自身所提供的服务名称来命名镜像的hostname，且不会对宿主机产生任何影响，其原理就是使用了UTS namespace。使用对比：没有使用UTS的情况运行结果如下：使用UTS的情况运行结果如下：可见，当使用UTS隔离之后，整个子进程的主机名和域名发生了改变。 3. IPC namespace 进程间通信（Inter-Process Communication, IPC）涉及的IPC资源包括常见的信号量、消息队列和共享内存，其标志位为CLONE_NEWIPC。对于IPC资源申请，申请IPC资源就申请了一个全局唯一的32位ID，因此，IPC namespace中实际上包含了系统IPC标识符以及实现POSIX消息队列的文件系统。在同一个IPC namespace下的进程彼此可见，不同IPC namespace下的进程则互相不可见。对于IPC namespace隔离的测试，可以参考：http://crosbymichael.com/creating-containers-part-1.html 4. PID namespace PID namespace隔离对进程PID重新标号，即两个不同namespace下的进程可以有相同的PID。每个PID namespace都有自己的计数程序，标志位为CLONE_NEWPID。内核为所有的PID namespace维护了一个树状结构，最顶层的是系统初始时创建的，被称为root namespace。它创建的新的PID namespace被称为child namespace（树的子节点），而原先的PID namespace就是创建的新的PID namespace的parent namespace（树的父节点）。通过这种方式，不同的PID namespace就会形成一个层级体系。所属的父节点可以看到子节点中的进程，并可以通过信号等方式对子节点中的进程产生影响，但是子节点却不能看到父节点PID namespace中的任何内容。关于PID namespace的相关结论：每个PID namespace中的第一个进程“PID 1”，都如同init进程一样具有特殊作用。 namespace中的进程不能通过kill或ptrace来影响父节点或兄弟节点中的进程。在root namespace中可以看到所有的进程，并且递归包含所有子节点中的进程。一种在外部监控Docker中运行程序的方法：监控Docker daemon所在的PID namespace下的所有进程及其子进程，再进行筛选即可。对于PID namespace中的init进程，其主要用于维护所有后续启动进程的运行状态。当系统中存在树状嵌套结构的PID namespace时，若某个子进程成为孤儿进程，收养该子进程的责任就交给了该子进程所属的PID namespace中的init进程。通观而言，PID namespace维护这样一个树状结构有利于系统的资源监控与回收。因此，如果确实需要在一个Docker容器中运行多个进程，最先启动的命令进程应该是具有资源监控与回收等管理能力的，如/bin/bash。另外，对于PID namespace中的init进程，其同时具有信号屏蔽的特权。也就是说，与init在同一个PID namespace下的进程（即使有超级权限）发送给它的所有信号都会被屏蔽，以防止init进程被误杀。但是，当父节点PID namespace中的进程发送相同的信号给子节点PID namespace中的init进程时，如果该信号是SIGKILL（销毁进程）或SIGSTOP（暂停进程），子节点的init进程会强制执行，其余的信号则会被忽略。同时，一旦init进程被销毁，同一PID namespace中的其他进程也随之接收到SIGKILL信号而被销毁。对于PID namespace的ps命令，如果只想看到PID namespace本身应该看到的进程，需要重新挂载/proc，命令如下： zjl@ubuntu:~$ mount -t proc proc /proc zjl@ubuntu:~$ ps a 5. mount namespace mount namespace通过隔离文件系统挂载点对文件系统的隔离提供支持，它是第一个Linux namespace，因此标志位比较特殊，为CLONE_NEWNS。可以通过/proc/[pid]/mount查看到所有挂载在当前namespace中的文件系统，还可以通过/proc/[pid]/mountstats看到mount namespace中文件设备的统计信息，包括挂载文件的名字、文件系统类型、挂在位置等。具体如下图所示： $ vim /proc/2430/mounts $ vim /proc/2430/mountstats 进程在创建mount namespace时，会把当前的文件结构复制给新的mount namespace。新的mount namespace中的所有mount操作都只影响自身的文件系统，对外界不会产生任何影响。 mount namespace机制：挂载传播（mount propagation）。挂载传播定义了挂载对象（mount object）之间的关系，这样的关系包括共享关系和从属关系，系统用这些关系决定任何挂载对象中的挂载事件如何传播到其他挂载对象。共享关系（share relationship）：如果两个挂载对象具有共享关系，那么一个挂载对象中的挂载事件会传播到另一个挂载对象，反之亦然。从属关系（slave relationship）：如果两个挂载对象形成从属关系，那么一个挂载对象中的挂载事件会传播到另一个挂载对象，但是反之不行。一个挂载状态可能为以下一种：共享挂载（shared）：传播事件的挂载对象。从属挂载（slave）：接收传播事件的挂载对象。私有挂载（private）：既不传播也不接收传播事件的挂载对象。不可绑定挂载（unbindable）：不允许执行绑定挂载。示意图如下：如图，可以得知： mount namespace下的/bin目录与child namespace通过master/slave方式进行挂载传播，当mount namespace中的/bin目录发生变化时，其挂载事件会自动传播到child namespace中； /lib目录使用完全的共享挂载传播，各namespace之间发生的变化都会互相影响； /proc目录使用私有挂载传播的方式，各个mount namespace之间相互隔离； /root目录一般都是管理员所有，不能让其他mount namespace挂载绑定。在默认情况下，所有挂载状态都是私有挂载。设置为共享挂载的命令如下： $ mount --make-shared <mount-object> 从共享挂载状态的挂载对象克隆的挂载对象，其状态也是共享的，它们互相传播挂载事件。设置为从属挂载的命令如下： $ mount --make-slave <shared-mount-object> 来源于从属挂载对象克隆的挂载对象也是从属挂载，它也从属于原来的从属挂载的主挂载对象。将一个从属挂载对象设置为共享/从属挂载的命令如下： $ mount --make-shared <slave-mount-object> 对于CLONE_NEWNS，当CLONE_NEWNS生效之后，子进程进行的挂载与卸载操作都将只作用于该mount namespace。 6. network namespace network namespace主要提供了关于网络资源的隔离，包括网络设备、IPv4和IPv6协议栈、IP路由表、防火墙、/proc/net目录、/sys/class/net目录以及套接字（socket）等。对于网络设备，其最多存在于一个network namespace中，可以通过创建veth pair在不同的network namespace间创建通道，以达到通信的目的。对于veth pair，其表示虚拟网络映射对，它有两端，类似管道，如果数据从一端传入，另一端也能接收到。一般情况下，物理网络设备都分配在最初的root namespace中，但是，如果有多块物理网卡，也可以把其中一块或多块分配给新创建的network namespace。对于network namespace，我们可以认为其是将网络独立出来，模拟一个独立网络实体与外部用户实体进行通信。对于该过程，容器的经典做法就是：创建一个veth pair，一端放置于新的network namespace中，通常命名为eth0，另一端放置在原来的network namespace中连接物理网络设备，然后，再通过把多个设备接入网桥或进行路由转发，以实现网络通信的目的。另外，在建立起veth pair之前，新的network namespace和旧的network namespace之间通过管道（pipe）来进行通信。具体示意图如下图所示：与其他namespace类似，对network namespace的使用其实就是在创建的时候添加CLONE_NEWNET标志位。 7. user namespace user namespace主要隔离了安全相关的标识符（identifier）和属性（attributes），包括用户ID、用户组ID、root目录、密钥以及特殊权限。也就是说，一个普通用户的进程通过clone()创建的新进程在新user namespace中可以拥有不同的用户和用户组。这意味着一个进程在容器外属于一个没有特权的普通用户，但是它创建的容器进程却属于拥有所有权限的超级用户。相应的，其在clone()中的标志位为CLONE_NEWUSER。 8. 小结本节从namespace使用的API开始，结合Docker逐步对6个namespace进行了讲解。二、cgroups资源限制对于cgroups，它可以用于限制被namespace隔离起来的资源，还可以为资源设置权重、计算使用量、操控任务启动和停止等。 1. cgroups概念 cgroups是Linux内核提供的一种机制，这种机制可以根据需求把一系列系统任务及其子任务整合（或分隔）到按资源划分等级的不同组内，从而为系统资源管理提供一个统一的框架。也就是说，cgroups可以限制、记录任务组所使用的物理资源（包括CPU、memory、IO等），为容器实现虚拟化提供了基本保证，是构建Docker等一系列虚拟化管理工具的基石。 cgroups具有如下四个特点： cgroups的API以一个伪文件系统的方式实现，用户态的程序可以通过文件操作实现cgroups的组织管理； cgroups的组织管理操作单元可以细粒度到线程级别，另外用户可以创建和销毁cgroup，从而实现资源再分配和管理；所有资源管理的功能都以子系统的方式实现，接口统一；子任务创建时与其父任务处于同一个cgroups的控制组。从本质上，cgroups是内核附加在程序上的一系列钩子（hook），通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。 2. cgroups作用从单个任务的资源控制到操作系统层面的虚拟化，cgroups提供了如下四大功能：资源限制：cgroups可以对任务使用的资源总额进行限制。优先级分配：通过分配的CPU时间片数量以及磁盘IO带宽大小，实际上就相当于控制了任务运行的优先级。资源统计：cgroups可以统计系统的资源使用量，如CPU使用时长等。任务控制：cgroups可以对任务执行挂起、恢复等操作。 3. cgroups结构在cgroups中，主要有如下几个术语： task（任务）：任务表示系统的一个进程或线程； cgroup（控制组）：cgroup是cgroups进行资源控制的单位，它表示按某种资源控制标准划分而成的任务组，包含一个或多个子系统。一个任务可以加入某个group，也可以从某个cgroup迁移到另外一个cgroup中； subsystem（子系统）：cgroups中的子系统就是一个资源调度控制器，如CPU子系统可以控制CPU时间分配，内存子系统可以限制cgroup内存使用量； hierachy（层级）：层级由一系列cgroup以一个树状结构排列而成，每个层级通过绑定对应的子系统进行资源控制。层级中的cgroup节点可以包含零或多个子节点，子节点继承父节点挂载的子系统。出于易于管理的目的，在Docker中，每个子系统独自构成一个层级。对于cgroups的组织结构，主要有以下几个基本规则：规则1：同一个层级可以附加一个或多个子系统。规则2：一个子系统可以附加到多个层级，当且仅当目标层级只有唯一一个子系统时。规则3：系统每次新建一个层级时，该系统上的所有任务默认加入这个新建层级的初始化cgroup，这个cgroup又称root cgroup。对于创建的每个层级，任务只能存在于其中一个cgroup中，即一个任务不能存在于同一个层级的不同cgroup中，但一个任务可以存在于不同层级中的多个cgroup中。如果操作时把一个任务添加到同一个层级的另一个cgroup中，则会将它从第一个cgroup中移除。规则4：任务在fork/clone自身时创建的子任务默认与原任务在同一个cgroup中，但是子任务允许被移动到不同的cgroup中。 4. cgroups子系统在cgroups中，子系统实际上就是cgroups的资源控制系统，每种子系统独立地控制一种资源，目前Docker使用如下9种子系统，具体如下： blkio：为块设备设定输入/输出限制，比如物理驱动设备（包括磁盘、固态硬盘、USB等）。 cpu：使用调度程序控制任务对CPU的使用。 cpuacct：自动生成cgroup中任务对CPU资源使用情况的报告。 cpuset：可以为cgroup中的任务分配独立的CPU和内存。 devices：可以开启或关闭cgroup中任务对设备的访问。 freezer：可以挂起或恢复cgroup中的任务。 memory：可以设定cgroup中任务对内存使用量的限定，并且自动生成这些任务对内存资源使用情况的报告。 perfevent：使用后使得cgroup中的任务可以进行统一的性能测试。 net_cls：Docker没有直接使用，它通过使用等级识别符（classid）标记网络数据包，从而允许Linux流量控制程序（TC：Traffic Controller）识别从具体cgroup中生成的数据包。 5. cgroups实现方式及工作原理 cgroups的实现本质上是给任务挂上钩子，当任务运行的过程中涉及某种资源时，就会触发钩子上所附带的子系统进行检测，然后根据资源类别的不同使用对应的技术进行资源限制和优先级分配。（1）cgroups如何判断资源超限及超出限额之后的措施对于不同的系统资源，cgroups提供了统一的接口对资源进行控制和统计，但限制的具体方式不尽相同。（2）cgroup的子系统与任务之间的关联关系实现上，cgroup与任务之间是多对多的关系，因此它们并不直接关联，而是通过一个中间结构把双向的关联信息记录起来。每个任务结构体task_struct都包含了一个指针，可以查询到对应cgroup的情况，同时也可以查询到各个子系统的状态，这些子系统状态中也包含了找到任务的指针，不同类型的子系统按需定义本身的控制信息结构体，最终在自定义的结构体中把子系统状态指针包含进去，然后内核通过container_of等宏定义来获取对应的结构体，关联到任务，以此达到资源限制的目的。在实际的使用过程中，需要通过挂载cgroup文件系统来新建一个层级结构，挂载时需要指定要绑定的子系统，缺省情况下默认绑定系统所有子系统。在将cgroup文件系统挂载以后，就可以像操作文件一样对cgroups的hierarchy层级进行浏览和操作管理（包括权限管理、子文件管理等等）。除了cgroup文件系统以外，内核没有为cgroups的访问和操作添加任何系统调用。当一个顶层的cgroup文件系统被卸载时，如果其中创建后代cgroup目录，那么就算上层的cgroup被卸载了，层级也是激活状态，其后代cgoup中的配置依旧有效。只有递归式的卸载层级中的所有cgoup，那个层级才会被真正删除。层级激活后，/proc目录下的每个task PID文件夹下都会新添加一个名为cgroup的文件，列出task所在的层级，对其进行控制的子系统及对应cgroup文件系统的路径。同时，一个cgroup创建完成，不管绑定了何种子系统，其目录下都会生成以下几个文件，用来描述cgroup的相应信息。同样，把相应信息写入这些配置文件就可以生效，内容如下： tasks：这个文件中罗列了所有在该cgroup中task的PID。该文件并不保证task的PID有序，把一个task的PID写到这个文件中就意味着把这个task加入这个cgroup中。 cgroup.procs：这个文件罗列所有在该cgroup中的线程组ID。该文件并不保证线程组ID有序和无重复。写一个线程组ID到这个文件就意味着把这个组中所有的线程加到这个cgroup中。 notify_on_release：填0或1，表示是否在cgroup中最后一个task退出时通知运行release agent，默认情况下是0，表示不运行。 release_agent：指定release agent执行脚本的文件路径（该文件在最顶层cgroup目录中存在），在这个脚本通常用于自动化umount无用的cgroup。可参考：http://www.infoq.com/cn/articles/docker-kernel-knowledge-cgroups-resource-isolation 6. 小结本节浅入深出地讲解了cgroups，从cgroups是什么，到cgroups该怎么用，最后对大量地cgroup子系统配置参数进行了梳理。

adoryn个人页面-阿里云开发者社区

个人介绍

擅长的技术

运维调试笔记：python中pip下载速度慢问题解决

Java并发编程：Java内存模型

Docker技术笔记：Ubuntu安装Docker CE

Docker技术剖析：Docker背后的内核知识

运维调试记录：Ubuntu下通过PPA方式安装Java 8并自动配置环境变量

经典文摘：Linux/Unix设计思想

Linux命令行参数解析

运维调试记录：SSH无法连接到远端Ubuntu

操作系统中堆和栈详解

C语言中宏与内联函数解析

技术原理：Python中range和xrange对比

运维调试记录：QSqlDatabase: QMYSQL driver not loaded

运维调试记录：Win7中文件或目录损坏且无法读取

技术原理：C语言中函数指针数组浅析

运维调试记录：Mininet: Cannot find required executable controller

运维调试记录：Ubuntu启动到字符界面和图形界面

运维调试记录：Ubuntu16.04安装MySQL和Python库MySQLdb步骤

Linux中Ctrl+C,Ctrl+Z,Ctrl+D说明

C语言中柔性数组解析

运维调试记录：C++ compile error: default argument given for parameter

运维调试记录：Ubuntu下通过PPA方式安装Java 8并自动配置环境变量

Docker技术剖析：Docker背后的内核知识

Docker技术笔记：Ubuntu安装Docker CE

Java并发编程：Java内存模型

运维调试笔记：python中pip下载速度慢问题解决