非科班秋招面试总结

目录

 

javaSE方面

HashMap与ConcurrentHashMap(hash冲突，扩容机制，1.7与1.8的区别，锁)

面向对象特点

泛型

String StringBuffer StringBuilder

Overload 与Override

abstract 与interface

final finally finalize

1.8的新特性

JVM方面

类加载机制

          类加载器

垃圾回收器的分类

          Java 8 的新特性

垃圾回收算法

双亲委托模型及其验证

Java内存模型

多线程：这部分是比较难的知识点，平时用的少，偏偏又爱问，没办法

实现多线程的方法，各有什么优缺点？

violatile关键字的作用？

Synchronized与ReentrantLock的区别

多线程同步有哪几种方法？

什么是死锁？如何避免死锁？

什么是乐观锁和悲观锁，如何实现乐观锁

多线程之间如何进行通信？

wait与sleep

线程池

CyclicBarrier和CountDownLatch的区别？

MySQL相关：

数据库隔离级别

三范式

存储引擎的分类

innodb和myisam的区别

聚集索引和非聚集索引

如何优化数据库

分库分表

主从复制

Redis 相关：

支持的类型

Redis 应用场景

持久化rdb和aof

key的长度限制

框架相关

SpringMVC流程

SpringIOC 及AOP原理

Spring事务

Dubbo和SpringBoot的区别

Hibernate与Mybatis的区别

Spring用到的设计模式

网络

七层模型和五层模型

三次挥手四次握手

滑动窗口协议

tcp和udp的区别

TIME_WAIT出现在哪里，为什么

ping的原理

ARP原理

http和https

常用加密算法

get和post的区别

AIO NIO BIO

select poll epoll

手撕代码

单例模式

二叉树按层打印

两个桟实现队列，两个队列实现桟

单链表反转

合并有序数组

合并链表

链表排序

打印菱形

字符串转整数

Linux相关：

常用命令

查看进程命令

查看端口

杀死进程

硬连接与软连接

定义全局变量

grep cut awk

查找命令

其他

cookie和session

Zookeeper的选举过程，协议

分布式事务，数据一致性

你了解哪些设计模式

servlet

如何解决Hash冲突

你看过哪些源码

平时如何学习的

Docker相关命令

---

javaSE方面

HashMap与ConcurrentHashMap(hash冲突，扩容机制，1.7与1.8的区别，锁)

Hashtable：

底层数组+链表实现，无论key还是value都不能是null，线程安全，实现线程安全的方式是在修改数据时锁住整个Hashtable，效率低，ConcurrentHashMap做了相关优化。

初始size为11，扩容：newsize = oldsize*2+1；

计算index的方法：index = （hash&0x7FFFFFFF）%tab.length;

HashMap:

底层数组+链表实现，可以存储null键和null值，线程不安全

初始size为16，扩容：newsize = oldsize*2,size一定为2的n次幂；

扩容针对整个Map，每次扩容时，原来数组中的元素一次重新计算存放位置，并重新插入。

插入元素后才判断该不该扩容，有可能无效扩容（插入后如果扩容，如果没有再次插入就会产生无效扩容）

当Map中元素总数超过entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀。

计算index方法：index = hash&(tab.length-1)

HashMap的初始值还要考虑加载因子：

哈希冲突：若干key的哈希值按数组大小取模后，如果落在同一个数组下标上，将组成一条Entry链，对key的查找需要遍历Entry链上的每个元素执行equals()比较。

加载因子：为了降低哈希冲突的概率，默认当HashMap中的键值对达到数组大小的75%时即会产生扩容。因此，如果预估容量是100，即需要设定100/75%=134d的数组大小。

空间换时间：如果希望加快Key查找的时间，还可以进一步降低加载因子，加大初始大小，以降低哈希冲突的概率。

HashMap和Hashtable都是用hash算法来决定其元素的存储，因此HashMap和Hashtable的hash表包含如下属性：

• 容量（capacity）：hash表中桶的数量
• 初始化容量（initial capacity）：创建hash表时桶的数量，HashMap允许在构造器中指定初始化容量
• 尺寸（size）：当前hash表中记录的数量
• 负载因子（load factor）：负载因子等于“size/capacity”。负载因子为0，表示空的hash表，0.5表示半满的散列表，依此类推。轻负载的散列表具有冲突少、适宜插入与查询的特点（但是使用Iterator迭代元素时比较慢）

除此之外，hash表里还有一个“负载极限”，“负载极限”是一个0～1的数值，“负载极限”决定了hash表的最大填满程度。当hash表中的负载因子达到指定的“负载极限”时，hash表会自动成倍地增加容量（桶的数量），并将原有的对象重新分配，放入新的桶内，这称为rehashing。

HashMap和Hashtable的构造器允许指定一个负载极限，HashMap和Hashtable默认的“负载极限”为0.75，这表明当该hash表的3/4已经被填满时，hash表会发生rehashing。

“负载极限”的默认值（0.75）是时间和空间成本上的一种折中：

• 较高的“负载极限”可以降低hash表所占用的内存空间，但会增加查询数据的时间开销，而查询是最频繁的操作（HashMap的get()与put()方法都要用到查询）
• 较低的“负载极限”会提高查询数据的性能，但会增加hash表所占用的内存开销

程序猿可以根据实际情况来调整“负载极限”值。

ConcurrentHashMap

• 底层采用分段的数组+链表实现，线程安全
• 通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)
• Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术
• 有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁
• 扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容

 

Hashtable和HashMap都实现了Map接口，但是Hashtable的实现是基于Dictionary抽象类的。Java5提供了ConcurrentHashMap，它是HashTable的替代，比HashTable的扩展性更好。

HashMap基于哈希思想，实现对数据的读写。当我们将键值对传递给put()方法时，它调用键对象的hashCode()方法来计算hashcode，然后找到bucket位置来存储值对象。当获取对象时，通过键对象的equals()方法找到正确的键值对，然后返回值对象。HashMap使用链表来解决碰撞问题，当发生碰撞时，对象将会储存在链表的下一个节点中。HashMap在每个链表节点中储存键值对对象。当两个不同的键对象的hashcode相同时，它们会储存在同一个bucket位置的链表中，可通过键对象的equals()方法来找到键值对。如果链表大小超过阈值（TREEIFY_THRESHOLD,8），链表就会被改造为树形结构。

在HashMap中，null可以作为键，这样的键只有一个，但可以有一个或多个键所对应的值为null。当get()方法返回null值时，即可以表示HashMap中没有该key，也可以表示该key所对应的value为null。因此，在HashMap中不能由get()方法来判断HashMap中是否存在某个key，应该用containsKey()方法来判断。而在Hashtable中，无论是key还是value都不能为null。

Hashtable是线程安全的，它的方法是同步的，可以直接用在多线程环境中。而HashMap则不是线程安全的，在多线程环境中，需要手动实现同步机制。

Hashtable与HashMap另一个区别是HashMap的迭代器（Iterator）是fail-fast迭代器，而Hashtable的enumerator迭代器不是fail-fast的。所以当有其它线程改变了HashMap的结构（增加或者移除元素），将会抛出ConcurrentModificationException，但迭代器本身的remove()方法移除元素则不会抛出ConcurrentModificationException异常。但这并不是一个一定发生的行为，要看JVM。

先看一下简单的类图：

  

从类图中可以看出来在存储结构中ConcurrentHashMap比HashMap多出了一个类Segment，而Segment是一个可重入锁。

ConcurrentHashMap是使用了锁分段技术来保证线程安全的。

锁分段技术：首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。 

ConcurrentHashMap提供了与Hashtable和SynchronizedMap不同的锁机制。Hashtable中采用的锁机制是一次锁住整个hash表，从而在同一时刻只能由一个线程对其进行操作；而ConcurrentHashMap中则是一次锁住一个桶。

ConcurrentHashMap默认将hash表分为16个桶，诸如get、put、remove等常用操作只锁住当前需要用到的桶。这样，原来只能一个线程进入，现在却能同时有16个写线程执行，并发性能的提升是显而易见的。

面向对象特点

抽象：抽象是将一类对象的共同特征总结出来构造类的过程，包括数据抽象和行为抽象两方面。抽象只关注对象有哪些属性和行为，并不关注这些行为的细节是什么。

继承：继承是从已有类得到继承信息创建新类的过程。提供继承信息的类被称为父类（超类、基类）；得到继承信息的类被称为子类（派生类）。继承让变化中的软件系统有了一定的延续性，同时继承也是封装程序中可变因素的重要手段。

封装：通常认为封装是把数据和操作数据的方法绑定起来，对数据的访问只能通过已定义的接口。面向对象的本质就是将现实世界描绘成一系列完全自治、封闭的对象。我们再类中编写的方法就是对实现细节的一种封装。可以说，封装就是隐藏一切可以隐藏的东西，只向外界提供最简单的编程接口。

多态性：多态性是指允许不同子类型的对象对同一消息做出不同的响应。简单的说就是用同样的对象引用调用同样的方法但是做了不同的事情。多态性分为编译时的多态性和运行时的多态性。如果将对象的方法视为对象向外界提供的服务，那么运行时的多态性可以解释为：当A系统访问B系统提供的服务时，B系统有多种提供服务的方式，但一切对A系统来说都是透明的。方法重载实现的是编译时的多态性（也称为前绑定），而方法重写实现的是运行时的多态性（也称为后绑定）。运行时的多态是面向对象最精髓的东西，要实现多态需要两件事情：方法重写（子类继承父类并重写父类中已有的或抽象的方法）；对象造型（用父类型引用子类型对象，这样同样的引用调用同样的方法就会根据子类对象的不同而表现出不同的行为）。

泛型

Java 泛型（generics）是 JDK 5 中引入的一个新特性, 泛型提供了编译时类型安全检测机制，该机制允许程序员在编译时检测到非法的类型。

泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。

假定我们有这样一个需求：写一个排序方法，能够对整型数组、字符串数组甚至其他任何类型的数组进行排序，该如何实现？

答案是可以使用 Java 泛型。

使用 Java 泛型的概念，我们可以写一个泛型方法来对一个对象数组排序。然后，调用该泛型方法来对整型数组、浮点数数组、字符串数组等进行排序。

泛型方法

你可以写一个泛型方法，该方法在调用时可以接收不同类型的参数。根据传递给泛型方法的参数类型，编译器适当地处理每一个方法调用。

下面是定义泛型方法的规则：

• 所有泛型方法声明都有一个类型参数声明部分（由尖括号分隔），该类型参数声明部分在方法返回类型之前（在下面例子中的<E>）。
• 每一个类型参数声明部分包含一个或多个类型参数，参数间用逗号隔开。一个泛型参数，也被称为一个类型变量，是用于指定一个泛型类型名称的标识符。
• 类型参数能被用来声明返回值类型，并且能作为泛型方法得到的实际参数类型的占位符。
• 泛型方法体的声明和其他方法一样。注意类型参数只能代表引用型类型，不能是原始类型（像int,double,char的等）。

• 实例
  public class GenericMethodTest
  {
     // 泛型方法 printArray                         
     public static < E > void printArray( E[] inputArray )
     {
        // 输出数组元素            
           for ( E element : inputArray ){        
              System.out.printf( "%s ", element );
           }
           System.out.println();
      }
   
      public static void main( String args[] )
      {
          // 创建不同类型数组： Integer, Double 和 Character
          Integer[] intArray = { 1, 2, 3, 4, 5 };
          Double[] doubleArray = { 1.1, 2.2, 3.3, 4.4 };
          Character[] charArray = { 'H', 'E', 'L', 'L', 'O' };
   
          System.out.println( "整型数组元素为:" );
          printArray( intArray  ); // 传递一个整型数组
   
          System.out.println( "\n双精度型数组元素为:" );
          printArray( doubleArray ); // 传递一个双精度型数组
   
          System.out.println( "\n字符型数组元素为:" );
          printArray( charArray ); // 传递一个字符型数组
      } 
  }
  
  编译以上代码，运行结果如下所示：
  
  整型数组元素为:
  1 2 3 4 5 
  
  双精度型数组元素为:
  1.1 2.2 3.3 4.4 
  
  字符型数组元素为:
  H E L L

   

String StringBuffer StringBuilder

这三个类之间的区别主要是在两个方面，即运行速度和线程安全这两方面。

1. 首先说运行速度，或者说是执行速度，在这方面运行速度快慢为：StringBuilder > StringBuffer > String

　　String最慢的原因：

　　String为字符串常量，而StringBuilder和StringBuffer均为字符串变量，即String对象一旦创建之后该对象是不可更改的，但后两者的对象是变量，是可以更改的。以下面一段代码为例：

1 String str="abc";
2 System.out.println(str);
3 str=str+"de";
4 System.out.println(str);

　　如果运行这段代码会发现先输出“abc”，然后又输出“abcde”，好像是str这个对象被更改了，其实，这只是一种假象罢了，JVM对于这几行代码是这样处理的，首先创建一个String对象str，并把“abc”赋值给str，然后在第三行中，其实JVM又创建了一个新的对象也名为str，然后再把原来的str的值和“de”加起来再赋值给新的str，而原来的str就会被JVM的垃圾回收机制（GC）给回收掉了，所以，str实际上并没有被更改，也就是前面说的String对象一旦创建之后就不可更改了。所以，Java中对String对象进行的操作实际上是一个不断创建新的对象并且将旧的对象回收的一个过程，所以执行速度很慢。

　　而StringBuilder和StringBuffer的对象是变量，对变量进行操作就是直接对该对象进行更改，而不进行创建和回收的操作，所以速度要比String快很多。

　　另外，有时候我们会这样对字符串进行赋值

1 String str="abc"+"de";
2 StringBuilder stringBuilder=new StringBuilder().append("abc").append("de");
3 System.out.println(str);
4 System.out.println(stringBuilder.toString());

　　这样输出结果也是“abcde”和“abcde”，但是String的速度却比StringBuilder的反应速度要快很多，这是因为第1行中的操作和

　　String str="abcde";

　　是完全一样的，所以会很快，而如果写成下面这种形式

1 String str1="abc";
2 String str2="de";
3 String str=str1+str2;

　　那么JVM就会像上面说的那样，不断的创建、回收对象来进行这个操作了。速度就会很慢。

　　2. 再来说线程安全

　　在线程安全上，StringBuilder是线程不安全的，而StringBuffer是线程安全的

　　如果一个StringBuffer对象在字符串缓冲区被多个线程使用时，StringBuffer中很多方法可以带有synchronized关键字，所以可以保证线程是安全的，但StringBuilder的方法则没有该关键字，所以不能保证线程安全，有可能会出现一些错误的操作。所以如果要进行的操作是多线程的，那么就要使用StringBuffer，但是在单线程的情况下，还是建议使用速度比较快的StringBuilder。

　　3. 总结一下
　　String：适用于少量的字符串操作的情况

　　StringBuilder：适用于单线程下在字符缓冲区进行大量操作的情况

　　StringBuffer：适用多线程下在字符缓冲区进行大量操作的情况

Overload 与Override

    Overload是重载的意思，Override是覆盖的意思，也就是重写。

    重载Overload：在同一个类中，允许存在一个以上的同名函数，只要他们的参数个数或者参数类型不同即可。

    重载的特点：与返回值类型无关，只看参数列表。

    重写Override表示子类中的方法可以与父类中的某个方法的名称和参数完全相同，通过子类创建的实例对象调用这个方法时，将调用子类中定义的方法，这相当于把父类中定义的那个完全相同的方法给覆盖掉了，这也是面向对象编程的多态的一种表现。子类覆盖父类方法时只能抛出父类的异常或者异常的子类或者父类异常的子集，因为子类可以解决父类的一些问题，但不能比父类有更多的问题。还有，子类方法的访问权限只能比父类的更大，不能更小。如果父类的方法是private类型，则子类中根本不存在覆盖，即子类中和父类的private的同名的方法没有覆盖的关系，因为private的访问权限只限于同一类中，而子类就不会访问到private的方法，所以是子类中增加的一个全新的方法。

    重载overload的特点就是与返回值无关，只看参数列表，所以重载的方法是可以改变返回值类型的。所以，如果两个方法的参数列表完全一样，是不能通过让他们的返回值类型不同来实现重载的。我们可以用反证法来说明这个问题，因为我们有时候调用一个方法时也可以不定义返回结果变量，即不要关心其返回结果，例如，我们调用map.remove(key)方法时，虽然remove方法有返回值，但是我们通常都不会定义接收返回结果的变量，这时候假设该类中有两个名称和参数列表完全相同的方法，仅仅是返回类型不同，java就无法确定编程者倒底是想调用哪个方法了，因为它无法通过返回结果类型来判断。

 

short s1=1; s1=s1+1;有什么错？

short s1=1;s1+=1;有什么错？

    对于前者，由于s1+1运算时会自动提升表达式的类型，所以结果是int类型，再赋值给short类型s1时，编译器会将报告需要强制转换类型的错误。

    对于后者，由于+=是java语言规定的运算符，java编译器会对它进行特殊处理，因此可以正常编译。

    补充：当一个java算数表达式中包含多个基本类型的数据时，整个算数表达式的类型将发生自动类型提升。java定义的如下自动提升规则：

            1.所有的byte型、short型和char型将被提升为int型。

            2.整个算数表达式的数据类型自动提升到与表达式中最高等级操作数同样的类型。操作数的等级排列如下图所示，位于箭头右边类型的等级高于位于箭头左边类型的等级。

             注：如果想把结果赋值给较小的类型，就必须使用类型转换（既然把结果赋给了较小的类型，就可能出现信息丢失）。

构造器Construct是否可被Override？

    构造器不能被继承，因此不能被重写Override，但可以被重载Override。

    补充：继承——子父类中的构造函数的特点：

            在子类构造对象时发现，访问子类构造函数时，父类也运行了。为什么呢？

            原因是：在子类的构造函数第一行有一个默认的隐式语句：super();

                       super();//调用的是父类中的空参数的构造函数。

            子类实例化过程：子类中所有的构造函数默认都会访问父类中的空参数的构造函数。

            为什么子类实例化的时候要访问父类中的构造函数呢？

            因为子类继承父类，获取了父类中的内容（属性），所以在使用父类内容之前，要先看父类是如何对自己的内容进行初始化的。所以子类在构造对象时，必须访问父类中的构造函数。为了完成这个必须的动作，就在子类的构造函数中加入了super()。

            如果父类中没有定义空参数构造函数，那么子类的构造函数必须用super明确要调用父类中的哪个构造函数。

    注意：super语句必须要定义在子类构造函数的第一行。因为父类的初始化动作要先完成。

            通过super()初始化父类内容时，子类的成员变量并未显示初始化，等super()父类初始化完毕后，才进行子类成员的显示初始化。

   

接口是否可继承接口？抽象类是否可实现(implements)接口？抽象类是否可以继承具体类？抽象类中是否可有静态的main方法？

        接口可以继承接口

        抽象类可以实现接口

        抽象类可以继承实体类，但和实体类的继承一样，也要求父类可继承，并且拥有子类可以访问到的构造器。

        抽象类中可以有静态的main方法。

     其实，抽象类和普通类的唯一区别就是不能创建实例对象和允许有abstract方法。

abstract 与interface

含有abstract修饰符的class即为抽象类，abstract 类不能创建的实例对象。含有abstract方法的类必须定义为abstract class，abstract class类中的方法不必是抽象的。abstract class类中定义抽象方法必须在具体(Concrete)子类中实现，所以，不能有抽象构造方法或抽象静态方法。如果子类没有实现抽象父类中的所有抽象方法，那么子类也必须定义为abstract类型。

　　接口（interface）可以说成是抽象类的一种特例，接口中的所有方法都必须是抽象的。接口中的方法定义默认为public abstract类型，接口中的成员变量类型默认为public static final。

 

下面比较一下两者的语法区别：

1.抽象类可以有构造方法，接口中不能有构造方法。

2.抽象类中可以有普通成员变量，接口中没有普通成员变量

3.抽象类中可以包含非抽象的普通方法，接口中的所有方法必须都是抽象的，不能有非抽象的普通方法。

4. 抽象类中的抽象方法的访问类型可以是public，protected和（默认类型,虽然eclipse下不报错，但应该也不行），但接口中的抽象方法只能是public类型的，并且默认即为public abstract类型。

5. 抽象类中可以包含静态方法，接口中不能包含静态方法

6. 抽象类和接口中都可以包含静态成员变量，抽象类中的静态成员变量的访问类型可以任意，但接口中定义的变量只能是public static final类型，并且默认即为public static final类型。

7. 一个类可以实现多个接口，但只能继承一个抽象类。

 

下面接着再说说两者在应用上的区别：

　　接口更多的是在系统架构设计方法发挥作用，主要用于定义模块之间的通信契约。而抽象类在代码实现方面发挥作用，可以实现代码的重用，例如，模板方法设计模式是抽象类的一个典型应用，假设某个项目的所有Servlet类都要用相同的方式进行权限判断、记录访问日志和处理异常，那么就可以定义一个抽象的基类，让所有的Servlet都继承这个抽象基类，在抽象基类的service方法中完成权限判断、记录访问日志和处理异常的代码，在各个子类中只是完成各自的业务逻辑代码。

final finally finalize

1、final修饰符（关键字）。被final修饰的类，就意味着不能再派生出新的子类，不能作为父类而被子类继承。因此一个类不能既被abstract声明，又被final声明。将变量或方法声明为final，可以保证他们在使用的过程中不被修改。被声明为final的变量必须在声明时给出变量的初始值，而在以后的引用中只能读取。被final声明的方法也同样只能使用，即不能方法重写。

public  class  finalTest{
final   int  a=6;//final成员变量不能被更改
final   int  b;//在声明final成员变量时没有赋值，称为空白final
public finalTest(){
b=8；//在构造方法中为空白final赋值
}
int   do(final x){//设置final参数，不可以修改参数x的值
return x+1;
}
void  doit(){
final int i = 7;//局部变量定义为final，不可改变i的值
}
}

2、finally是在异常处理时提供finally块来执行任何清除操作。不管有没有异常被抛出、捕获，finally块都会被执行。try块中的内容是在无异常时执行到结束。catch块中的内容，是在try块内容发生catch所声明的异常时，跳转到catch块中执行。finally块则是无论异常是否发生，都会执行finally块的内容，所以在代码逻辑中有需要无论发生什么都必须执行的代码，就可以放在finally块中。

3、finalize是方法名。java技术允许使用finalize（）方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。这个方法是由垃圾收集器在确定这个对象没有被引用时对这个对象调用的。它是在object类中定义的，因此所有的类都继承了它。子类覆盖finalize（）方法以整理系统资源或者被执行其他清理工作。finalize（）方法是在垃圾收集器删除对象之前对这个对象调用的。
 

1.8的新特性

• JVM方面

类加载机制

JVM类加载机制分为五个部分：加载、验证、准备、解析、初始化。

加载是类加载的一个阶段，这个阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的入口。注意这里不一定非要从一个Class文件获取，这里既可以从ZIP包中读取（比如从jar包和war包中读取），也可以在运行时计算生成（动态代理），也可以由其他文件生成（比如将JSP文件转换成对应的Class类）。

验证阶段的主要目的是为了确保Class文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使用的内存空间。注意这里所说的初始值概念，比如一个类变量定义为：

public static int v = 8080;

实际上变量v在准备阶段过后的初始值为0而不是8080，将v赋值为8080的put static指令是程序被编译后，存放于类构造器<client>方法之中。但是注意如果声明为：

public  static final int v = 8080;

在编译阶段会为v生成ConstantValue属性，在准备阶段虚拟机会根据ConstantValue属性将v赋值为8080.

解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。符号引用就是class文件中的：

• CONSTANT_Class_info
• CONSTANT_Field_info
• CONSTANT_Method_info

等类型的常量。

下面我们解释一下符号引用和直接引用的概念：

• 符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
• 直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在。

初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由JVM主导。到了初始阶段，才开始真正执行类中定义的Java程序代码。

初始化阶段是执行类构造器<client>方法的过程。<client>方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证<client>方法执行之前，父类的<client>方法已经执行完毕。p.s: 如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成<client>()方法。

注意以下几种情况不会执行类初始化：

• 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
• 定义对象数组，不会触发该类的初始化。
• 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
• 通过类名获取Class对象，不会触发类的初始化。
• 通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
• 通过ClassLoader默认的loadClass方法，也不会触发初始化动作。

类加载器

虚拟机设计团队把加载动作放到JVM外部实现，以便让应用程序决定如何获取所需的类，JVM提供了3种类加载器：

• 启动类加载器(Bootstrap ClassLoader)：负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath参数指定路径中的，且被虚拟机认可（按文件名识别，如rt.jar）的类。
• 扩展类加载器(Extension ClassLoader)：负责加载 JAVA_HOME\lib\ext 目录中的，或通过java.ext.dirs系统变量指定路径中的类库。
• 应用程序类加载器(Application ClassLoader)：负责加载用户路径（classpath）上的类库。

JVM通过双亲委派模型进行类的加载，当然我们也可以通过继承java.lang.ClassLoader实现自定义的类加载器。

当一个类加载器收到类加载任务，会先交给其父类加载器去完成，因此最终加载任务都会传递到顶层的启动类加载器，只有当父类加载器无法完成加载任务时，才会尝试执行加载任务。

采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。

在有些情境中可能会出现要我们自己来实现一个类加载器的需求，由于这里涉及的内容比较广泛，我想以后单独写一篇文章来讲述，不过这里我们还是稍微来看一下。我们直接看一下jdk中的ClassLoader的源码实现：

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

protected synchronized Class<?> loadClass(String name, boolean resolve)         throws ClassNotFoundException {     // First, check if the class has already been loaded     Class c = findLoadedClass(name);     if (c == null) {         try {             if (parent != null) {                 c = parent.loadClass(name, false);             } else {                 c = findBootstrapClass0(name);             }         } catch (ClassNotFoundException e) {             // If still not found, then invoke findClass in order             // to find the class.             c = findClass(name);         }     }     if (resolve) {         resolveClass(c);     }     return c; }

• 首先通过Class c = findLoadedClass(name);判断一个类是否已经被加载过。
• 如果没有被加载过执行if (c == null)中的程序，遵循双亲委派的模型，首先会通过递归从父加载器开始找，直到父类加载器是Bootstrap ClassLoader为止。
• 最后根据resolve的值，判断这个class是否需要解析。

而上面的findClass()的实现如下，直接抛出一个异常，并且方法是protected，很明显这是留给我们开发者自己去实现的，这里我们以后我们单独写一篇文章来讲一下如何重写findClass方法来实现我们自己的类加载器。

1 2 3

protected Class<?> findClass(String name) throws ClassNotFoundException {     throw new ClassNotFoundException(name); }

垃圾回收器的分类

Java有四种类型的垃圾回收器：

1. 串行垃圾回收器（Serial Garbage Collector）
2. 并行垃圾回收器（Parallel Garbage Collector）
3. 并发标记扫描垃圾回收器（CMS Garbage Collector）
4. G1垃圾回收器（G1 Garbage Collector）

每种类型都有自己的优势与劣势。重要的是，我们编程的时候可以通过JVM选择垃圾回收器类型。我们通过向JVM传递参数进行选择。每种类型在很大程度上有 所不同并且可以为我们提供完全不同的应用程序性能。理解每种类型的垃圾回收器并且根据应用程序选择进行正确的选择是非常重要的。

1、串行垃圾回收器

串行垃圾回收器通过持有应用程序所有的线程进行工作。它为单线程环境设计，只使用一个单独的线程进行垃圾回收，通过冻结所有应用程序线程进行工作，所以可能不适合服务器环境。它最适合的是简单的命令行程序。

通过JVM参数-XX:+UseSerialGC可以使用串行垃圾回收器。

2、并行垃圾回收器

并行垃圾回收器也叫做 throughput collector 。它是JVM的默认垃圾回收器。与串行垃圾回收器不同，它使用多线程进行垃圾回收。相似的是，它也会冻结所有的应用程序线程当执行垃圾回收的时候

3、并发标记扫描垃圾回收器

并发标记垃圾回收使用多线程扫描堆内存，标记需要清理的实例并且清理被标记过的实例。并发标记垃圾回收器只会在下面两种情况持有应用程序所有线程。

1. 当标记的引用对象在tenured区域；
2. 在进行垃圾回收的时候，堆内存的数据被并发的改变。

相比并行垃圾回收器，并发标记扫描垃圾回收器使用更多的CPU来确保程序的吞吐量。如果我们可以为了更好的程序性能分配更多的CPU，那么并发标记上扫描垃圾回收器是更好的选择相比并发垃圾回收器。

通过JVM参数 XX:+USeParNewGC 打开并发标记扫描垃圾回收器。

4、G1垃圾回收器

G1垃圾回收器适用于堆内存很大的情况，他将堆内存分割成不同的区域，并且并发的对其进行垃圾回收。G1也可以在回收内存之后对剩余的堆内存空间进行压缩。并发扫描标记垃圾回收器在STW情况下压缩内存。G1垃圾回收会优先选择第一块垃圾最多的区域

通过JVM参数 –XX:+UseG1GC 使用G1垃圾回收器

Java 8 的新特性

在使用G1垃圾回收器的时候，通过 JVM参数 -XX:+UseStringDeduplication 。 我们可以通过删除重复的字符串，只保留一个char[]来优化堆内存。这个选择在Java 8 u 20被引入。

我们给出了全部的四种Java垃圾回收器，需要根据应用场景，硬件性能和吞吐量需求来决定使用哪一种。

垃圾回收算法

Java虚拟机的内存区域中，程序计数器、虚拟机栈和本地方法栈三个区域是线程私有的，随线程生而生，随线程灭而灭；栈中的栈帧随着方法的进入和退出而进行入栈和出栈操作，每个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这三个区域的内存分配和回收都具有确定性。垃圾回收重点关注的是堆和方法区部分的内存。

常用的垃圾回收算法有：

(1).引用计数算法：

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不再被使用的，垃圾收集器将回收该对象使用的内存。

引用计数算法实现简单，效率很高，微软的COM技术、ActionScript、Python等都使用了引用计数算法进行内存管理，但是引用计数算法对于对象之间相互循环引用问题难以解决，因此java并没有使用引用计数算法。

(2).根搜索算法：

通过一系列的名为“GC Root”的对象作为起点，从这些节点向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Root没有任何引用链相连时，则该对象不可达，该对象是不可使用的，垃圾收集器将回收其所占的内存。

主流的商用程序语言C#、java和Lisp都使用根搜素算法进行内存管理。

在java语言中，可作为GC Root的对象包括以下几种对象：

a. java虚拟机栈(栈帧中的本地变量表)中的引用的对象。

b.方法区中的类静态属性引用的对象。

c.方法区中的常量引用的对象。

d.本地方法栈中JNI本地方法的引用对象。

java方法区在Sun HotSpot虚拟机中被称为永久代，很多人认为该部分的内存是不用回收的，java虚拟机规范也没有对该部分内存的垃圾收集做规定，但是方法区中的废弃常量和无用的类还是需要回收以保证永久代不会发生内存溢出。

判断废弃常量的方法：如果常量池中的某个常量没有被任何引用所引用，则该常量是废弃常量。

判断无用的类：

(1).该类的所有实例都已经被回收，即java堆中不存在该类的实例对象。

(2).加载该类的类加载器已经被回收。

(3).该类所对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射机制访问该类的方法。

Java中常用的垃圾收集算法：

(1).标记-清除算法：

最基础的垃圾收集算法，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成之后统一回收掉所有被标记的对象。

标记-清除算法的缺点有两个：首先，效率问题，标记和清除效率都不高。其次，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多会导致当程序需要为较大对象分配内存时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

(2).复制算法：

将可用内存按容量分成大小相等的两块，每次只使用其中一块，当这块内存使用完了，就将还存活的对象复制到另一块内存上去，然后把使用过的内存空间一次清理掉。这样使得每次都是对其中一块内存进行回收，内存分配时不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

复制算法的缺点显而易见，可使用的内存降为原来一半。

(3).标记-整理算法：

标记-整理算法在标记-清除算法基础上做了改进，标记阶段是相同的标记出所有需要回收的对象，在标记完成之后不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，在移动过程中清理掉可回收的对象，这个过程叫做整理。

标记-整理算法相比标记-清除算法的优点是内存被整理以后不会产生大量不连续内存碎片问题。

复制算法在对象存活率高的情况下就要执行较多的复制操作，效率将会变低，而在对象存活率高的情况下使用标记-整理算法效率会大大提高。

(4).分代收集算法：

根据内存中对象的存活周期不同，将内存划分为几块，java的虚拟机中一般把内存划分为新生代和年老代，当新创建对象时一般在新生代中分配内存空间，当新生代垃圾收集器回收几次之后仍然存活的对象会被移动到年老代内存中，当大对象在新生代中无法找到足够的连续内存时也直接在年老代中创建。

现在的Java虚拟机就联合使用了分代复制、标记-清除和标记-整理算法，java虚拟机垃圾收集器关注的内存结构如下：

堆内存被分成新生代和年老代两个部分，整个堆内存使用分代复制垃圾收集算法。

(1).新生代：

新生代使用复制和标记-清除垃圾收集算法，研究表明，新生代中98%的对象是朝生夕死的短生命周期对象，所以不需要将新生代划分为容量大小相等的两部分内存，而是将新生代分为Eden区，Survivor from和Survivor to三部分，其占新生代内存容量默认比例分别为8：1：1，其中Survivor from和Survivor to总有一个区域是空白，只有Eden和其中一个Survivor总共90%的新生代容量用于为新创建的对象分配内存，只有10%的Survivor内存浪费，当新生代内存空间不足需要进行垃圾回收时，仍然存活的对象被复制到空白的Survivor内存区域中，Eden和非空白的Survivor进行标记-清理回收，两个Survivor区域是轮换的。

新生代中98%情况下空白Survivor都可以存放垃圾回收时仍然存活的对象，2%的极端情况下，如果空白Survivor空间无法存放下仍然存活的对象时，使用内存分配担保机制，直接将新生代依然存活的对象复制到年老代内存中，同时对于创建大对象时，如果新生代中无足够的连续内存时，也直接在年老代中分配内存空间。

Java虚拟机对新生代的垃圾回收称为Minor GC，次数比较频繁，每次回收时间也比较短。

使用java虚拟机-Xmn参数可以指定新生代内存大小。

(2).年老代：

年老代中的对象一般都是长生命周期对象，对象的存活率比较高，因此在年老代中使用标记-整理垃圾回收算法。

Java虚拟机对年老代的垃圾回收称为MajorGC/Full GC，次数相对比较少，每次回收的时间也比较长。

当新生代中无足够空间为对象创建分配内存，年老代中内存回收也无法回收到足够的内存空间，并且新生代和年老代空间无法在扩展时，堆就会产生OutOfMemoryError异常。

java虚拟机-Xms参数可以指定最小内存大小，-Xmx参数可以指定最大内存大小，这两个参数分别减去Xmn参数指定的新生代内存大小，可以计算出年老代最小和最大内存容量。

(3).永久代：

java虚拟机内存中的方法区在Sun HotSpot虚拟机中被称为永久代，是被各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。永久代垃圾回收比较少，效率也比较低，但是也必须进行垃圾回收，否则会永久代内存不够用时仍然会抛出OutOfMemoryError异常。

永久代也使用标记-整理算法进行垃圾回收，java虚拟机参数-XX:PermSize和-XX:MaxPermSize可以设置永久代的初始大小和最大容量。

双亲委托模型及其验证

JVM在加载类时默认采用的是双亲委派模型。当某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，直至启动类加载器。如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，自己才尝试去加载。

这种层次关系称为类加载器的双亲委派模型。我们把每一层上面的类加载器叫做当前层类加载器的父加载器，它们之间的父子关系不是通过继承关系实现，而是使用组合关系复用父加载器中的代码。

双亲委派模型并不是一个强制性的约束模型，而是 Java 设计者们推荐给开发者的一种类的加载器实现方式。

使用双亲委派模型来组织类加载器之间的关系，很明显的好处就是 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。

例如，类 java.lang.Object 类存放在 \jre\lib 下的rt.jar之中，无论哪个类加载器加载此类，最终都会委派给启动类加载器进行加载，保证了 Object 类在程序中的各种类加载器中都是同一个类。因此，如果开发者尝试编写一个与rt.jar类库中重名的Java类，可以正常编译，但是永远无法被加载运行。

双亲委派模型的系统实现
除了启动类加载器，其它加载器都继承了ClassLoader抽象类，其中有一个loadClass()方法。

该方法会先检测该类有没有被加载过，没有则调用父类加载器进行加载；如果没有父类加载器，调用启动类加载器进行加载。如果都没有加载成功，调用自己的findClass()方法进行加载。

如下所示：

protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
    // First, check if the class has already been loaded
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            // ClassNotFoundException thrown if class not found
            // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                long t1 = System.nanoTime();
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

Java内存模型

在并发编程中，多个线程之间采取什么机制进行通信（信息交换），什么机制进行数据的同步？

在Java语言中，采用的是共享内存模型来实现多线程之间的信息交换和数据同步的。

　　线程之间通过共享程序公共的状态，通过读-写内存中公共状态的方式来进行隐式的通信。同步指的是程序在控制多个线程之间执行程序的相对顺序的机制，在共享内存模型中，同步是显式的，程序员必须显式指定某个方法/代码块需要在多线程之间互斥执行。

　　在说Java内存模型之前，我们先说一下Java的内存结构，也就是运行时的数据区域：

　　Java虚拟机在执行Java程序的过程中，会把它管理的内存划分为几个不同的数据区域，这些区域都有各自的用途、创建时间、销毁时间。

  Java运行时数据区分为下面几个内存区域：                                                                                               

　

1.PC寄存器/程序计数器：

　　严格来说是一个数据结构，用于保存当前正在执行的程序的内存地址，由于Java是支持多线程执行的，所以程序执行的轨迹不可能一直都是线性执行。当有多个线程交叉执行时，被中断的线程的程序当前执行到哪条内存地址必然要保存下来，以便用于被中断的线程恢复执行时再按照被中断时的指令地址继续执行下去。为了线程切换后能恢复到正确的执行位置，每个线程都需要有一个独立的程序计数器，各个线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存,这在某种程度上有点类似于“ThreadLocal”，是线程安全的。

2.Java栈 Java Stack：

　　Java栈总是与线程关联在一起的，每当创建一个线程，JVM就会为该线程创建对应的Java栈，在这个Java栈中又会包含多个栈帧(Stack Frame)，这些栈帧是与每个方法关联起来的，每运行一个方法就创建一个栈帧，每个栈帧会含有一些局部变量、操作栈和方法返回值等信息。每当一个方法执行完成时，该栈帧就会弹出栈帧的元素作为这个方法的返回值，并且清除这个栈帧，Java栈的栈顶的栈帧就是当前正在执行的活动栈，也就是当前正在执行的方法，PC寄存器也会指向该地址。只有这个活动的栈帧的本地变量可以被操作栈使用，当在这个栈帧中调用另外一个方法时，与之对应的一个新的栈帧被创建，这个新创建的栈帧被放到Java栈的栈顶，变为当前的活动栈。同样现在只有这个栈的本地变量才能被使用，当这个栈帧中所有指令都完成时，这个栈帧被移除Java栈，刚才的那个栈帧变为活动栈帧，前面栈帧的返回值变为这个栈帧的操作栈的一个操作数。

　　由于Java栈是与线程对应起来的，Java栈数据不是线程共有的，所以不需要关心其数据一致性，也不会存在同步锁的问题。

　　在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。在Hot Spot虚拟机中，可以使用-Xss参数来设置栈的大小。栈的大小直接决定了函数调用的可达深度。

                                                   

 

3.堆 Heap:

　　堆是JVM所管理的内存中最大的一块，是被所有Java线程锁共享的，不是线程安全的，在JVM启动时创建。堆是存储Java对象的地方，这一点Java虚拟机规范中描述是：所有的对象实例以及数组都要在堆上分配。Java堆是GC管理的主要区域，从内存回收的角度来看，由于现在GC基本都采用分代收集算法，所以Java堆还可以细分为：新生代和老年代；新生代再细致一点有Eden空间、From Survivor空间、To Survivor空间等。

4.方法区Method Area:

　　方法区存放了要加载的类的信息（名称、修饰符等）、类中的静态常量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，当在程序中通过Class对象的getName.isInterface等方法来获取信息时，这些数据都来源于方法区。方法区是被Java线程锁共享的，不像Java堆中其他部分一样会频繁被GC回收，它存储的信息相对比较稳定，在一定条件下会被GC，当方法区要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。方法区也是堆中的一部分，就是我们通常所说的Java堆中的永久区 Permanet Generation，大小可以通过参数来设置,可以通过-XX:PermSize指定初始值，-XX:MaxPermSize指定最大值。

5.常量池Constant Pool:

　　常量池本身是方法区中的一个数据结构。常量池中存储了如字符串、final变量值、类名和方法名常量。常量池在编译期间就被确定，并保存在已编译的.class文件中。一般分为两类：字面量和引用量。字面量就是字符串、final变量等。类名和方法名属于引用量。引用量最常见的是在调用方法的时候，根据方法名找到方法的引用，并以此定为到函数体进行函数代码的执行。引用量包含：类和接口的权限定名、字段的名称和描述符，方法的名称和描述符。

6.本地方法栈Native Method Stack:

　　本地方法栈和Java栈所发挥的作用非常相似，区别不过是Java栈为JVM执行Java方法服务，而本地方法栈为JVM执行Native方法服务。本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。

主内存和工作内存：

　　Java内存模型的主要目标是定义程序中各个变量的访问规则，即在JVM中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量与Java编程里面的变量有所不同步，它包含了实例字段、静态字段和构成数组对象的元素，但不包含局部变量和方法参数，因为后者是线程私有的，不会共享，当然不存在数据竞争问题（如果局部变量是一个reference引用类型，它引用的对象在Java堆中可被各个线程共享，但是reference引用本身在Java栈的局部变量表中，是线程私有的）。为了获得较高的执行效能，Java内存模型并没有限制执行引起使用处理器的特定寄存器或者缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。

　　JMM规定了所有的变量都存储在主内存（Main Memory）中。每个线程还有自己的工作内存（Working Memory）,线程的工作内存中保存了该线程使用到的变量的主内存的副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量（volatile变量仍然有工作内存的拷贝，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般）。不同的线程之间也无法直接访问对方工作内存中的变量，线程之间值的传递都需要通过主内存来完成。

                                                                   

 

　　线程1和线程2要想进行数据的交换一般要经历下面的步骤：

　　1.线程1把工作内存1中的更新过的共享变量刷新到主内存中去。

　　2.线程2到主内存中去读取线程1刷新过的共享变量，然后copy一份到工作内存2中去。

 

 Java内存模型是围绕着并发编程中原子性、可见性、有序性这三个特征来建立的，那我们依次看一下这三个特征：

　　原子性（Atomicity）：一个操作不能被打断，要么全部执行完毕，要么不执行。在这点上有点类似于事务操作，要么全部执行成功，要么回退到执行该操作之前的状态。

　　基本类型数据的访问大都是原子操作，long 和double类型的变量是64位，但是在32位JVM中，32位的JVM会将64位数据的读写操作分为2次32位的读写操作来进行，这就导致了long、double类型的变量在32位虚拟机中是非原子操作，数据有可能会被破坏，也就意味着多个线程在并发访问的时候是线程非安全的。

多线程：这部分是比较难的知识点，平时用的少，偏偏又爱问，没办法

实现多线程的方法，各有什么优缺点？

violatile关键字的作用？

Synchronized与ReentrantLock的区别

多线程同步有哪几种方法？

什么是死锁？如何避免死锁？

什么是乐观锁和悲观锁，如何实现乐观锁

多线程之间如何进行通信？

wait与sleep

线程池

CyclicBarrier和CountDownLatch的区别？

MySQL相关：

数据库隔离级别

三范式

存储引擎的分类

innodb和myisam的区别

聚集索引和非聚集索引

如何优化数据库

分库分表

主从复制

Redis 相关：

支持的类型

Redis 应用场景

持久化rdb和aof

key的长度限制

框架相关

SpringMVC流程

SpringIOC 及AOP原理

Spring事务

Dubbo和SpringBoot的区别

Hibernate与Mybatis的区别

Spring用到的设计模式

网络

七层模型和五层模型

OSI参考模型，即开放式系统互联，一般叫OSI参考模型。OSI定义了网络互联的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）。

各层功能定义

        这里我们只对OSI各层进行功能上的大概阐述，不详细深究，因为每一层实际都是一个复杂的层。后面我也会根据个人方向展开部分层的深入学习。这里我们就大概了解一下。我们从最顶层——应用层 开始介绍。整个过程以公司A和公司B的一次商业报价单发送为例子进行讲解。

<1>    应用层

        OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。

        实际公司A的老板就是我们所述的用户，而他要发送的商业报价单，就是应用层提供的一种网络服务，当然，老板也可以选择其他服务，比如说，发一份商业合同，发一份询价单，等等。

<2>    表示层

        表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

        由于公司A和公司B是不同国家的公司，他们之间的商定统一用英语作为交流的语言，所以此时表示层（公司的文秘），就是将应用层的传递信息转翻译成英语。同时为了防止别的公司看到，公司A的人也会对这份报价单做一些加密的处理。这就是表示的作用，将应用层的数据转换翻译等。

<3>    会话层

        会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。      

        会话层的同事拿到表示层的同事转换后资料，（会话层的同事类似公司的外联部），会话层的同事那里可能会掌握本公司与其他好多公司的联系方式，这里公司就是实际传递过程中的实体。他们要管理本公司与外界好多公司的联系会话。当接收到表示层的数据后，会话层将会建立并记录本次会话，他首先要找到公司B的地址信息，然后将整份资料放进信封，并写上地址和联系方式。准备将资料寄出。等到确定公司B接收到此份报价单后，此次会话就算结束了，外联部的同事就会终止此次会话。

<4>   传输层

        传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。

        传输层就相当于公司中的负责快递邮件收发的人，公司自己的投递员，他们负责将上一层的要寄出的资料投递到快递公司或邮局。

<5>   网络层

       本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。

        网络层就相当于快递公司庞大的快递网络，全国不同的集散中心，比如说，从深圳发往北京的顺丰快递（陆运为例啊，空运好像直接就飞到北京了），首先要到顺丰的深圳集散中心，从深圳集散中心再送到武汉集散中心，从武汉集散中心再寄到北京顺义集散中心。这个每个集散中心，就相当于网络中的一个IP节点。

<6>   数据链路层 

        将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。

     数据链路层又分为2个子层：逻辑链路控制子层（LLC）和媒体访问控制子层（MAC）。

        MAC子层处理CSMA/CD算法、数据出错校验、成帧等；LLC子层定义了一些字段使上次协议能共享数据链路层。 在实际使用中，LLC子层并非必需的。

        这个没找到合适的例子

<7>  物理层     

        实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

         快递寄送过程中的交通工具，就相当于我们的物理层，例如汽车，火车，飞机，船。

TCP/IP五层模型

物理层、数据链路层、网络层、传输层和应用层。

三次挥手四次握手

1、三次握手

（1）三次握手的详述

首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

 

 最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）

• B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。
• 1）第一次握手：A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段，（首部的同步位SYN=1，初始序号seq=x），（SYN=1的报文段不能携带数据）但要消耗掉一个序号，此时TCP客户进程进入SYN-SENT（同步已发送）状态。
• 2）第二次握手：B收到连接请求报文段后，如同意建立连接，则向A发送确认，在确认报文段中（SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y），测试TCP服务器进程进入SYN-RCVD（同步收到）状态；
• 3）第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段（ACK=1，确认号ack=y+1，序号seq=x+1）（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。TCP连接已经建立，A进入ESTABLISHED（已建立连接）。
• 当B收到A的确认后，也进入ESTABLISHED状态。

（2）总结三次握手过程：

• 第一次握手：起初两端都处于CLOSED关闭状态，Client将标志位SYN置为1，随机产生一个值seq=x，并将该数据包发送给Server，Client进入SYN-SENT状态，等待Server确认；
• 第二次握手：Server收到数据包后由标志位SYN=1得知Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给Client以确认连接请求，Server进入SYN-RCVD状态，此时操作系统为该TCP连接分配TCP缓存和变量；
• 第三次握手：Client收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并且此时操作系统为该TCP连接分配TCP缓存和变量，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client和Server就可以开始传输数据。

起初A和B都处于CLOSED状态——B创建TCB，处于LISTEN状态，等待A请求——A创建TCB，发送连接请求（SYN=1，seq=x），进入SYN-SENT状态——B收到连接请求，向A发送确认（SYN=ACK=1，确认号ack=x+1，初始序号seq=y），进入SYN-RCVD状态——A收到B的确认后，给B发出确认（ACK=1，ack=y+1，seq=x+1），A进入ESTABLISHED状态——B收到A的确认后，进入ESTABLISHED状态。

TCB传输控制块Transmission Control Block，存储每一个连接中的重要信息，如TCP连接表，到发送和接收缓存的指针，到重传队列的指针，当前的发送和接收序号。

（3）为什么A还要发送一次确认呢？可以二次握手吗？

　　答：主要为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。如A发出连接请求，但因连接请求报文丢失而未收到确认，于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，A工发出了两个连接请求报文段，其中第一个丢失，第二个到达了B，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接，不采用三次握手，只要B发出确认，就建立新的连接了，此时A不理睬B的确认且不发送数据，则B一致等待A发送数据，浪费资源。

（4）Server端易受到SYN攻击？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。

2、四次挥手

（1）四次挥手的详述

　　假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

 

 数据传输结束后，通信的双方都可释放连接，A和B都处于ESTABLISHED状态。（A、B连接建立状态ESTABLISHED——A终止等待1状态FIN-WAIT-1——B关闭等待状态CLOSE-WAIT——A终止等待2状态FIN-WAIT-2——B最后确认状态LAST-ACK——A时间等待状态TIME-WAIT——B、A关闭状态CLOSED）

• 1）A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
• 2）B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
• 3）A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
• 4）B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
• 5）A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

（2）总结四次挥手过程：

起初A和B处于ESTABLISHED状态——A发出连接释放报文段并处于FIN-WAIT-1状态——B发出确认报文段且进入CLOSE-WAIT状态——A收到确认后，进入FIN-WAIT-2状态，等待B的连接释放报文段——B没有要向A发出的数据，B发出连接释放报文段且进入LAST-ACK状态——A发出确认报文段且进入TIME-WAIT状态——B收到确认报文段后进入CLOSED状态——A经过等待计时器时间2MSL后，进入CLOSED状态。

（3）为什么A在TIME-WAIT状态必须等待2MSL的时间？

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2

答：　　两个理由：1）保证A发送的最后一个ACK报文段能够到达B。2）防止“已失效的连接请求报文段”出现在本连接中。

• 1）这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。
• 2）A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

（4）为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

（5）为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

滑动窗口协议

   分析：

①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；

②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；

③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；

④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；

⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；

⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；

⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；

⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。

    若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。

1. 1比特滑动窗口协议：发送窗口=1，接收窗口=1；
2. 后退n协议：发窗口>1，接收窗口>1；
3. 选择重传协议：发送窗口>1,接收窗口>1。

1比特滑动窗口协议

    当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。

  

后退n协议

    由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。

   从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。

选择重传协议

    在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。

滑动窗口协议

仍然考虑链路的延迟与带宽的乘积为8 K B，帧尺寸为1 K B的情形。让发送方在收到第一帧的A C K的同时准备发送第九帧。允许我们这样做的算法称为滑动窗口（ sliding window），时间线如图2 - 2 1所示。

1. 滑动窗口算法

---

滑动窗口算法工作过程如下。首先，发送方为每1帧赋一个序号（sequence number），记作S e q N u m。现在，让我们忽略S e q N u m是由有限大小的头部字段实现的事实，而假设它能无限增大。发送方维护3个变量：发送窗口大小（send window size），记作S W S，给出发送方能够发 

送但未确认的帧数的上界； L A R表示最近收到的确认帧（ last acknowledgement re c e i v e d）的序号；L F S表示最近发送的帧（last frame sent）的序号，发送方还维持如下的不变式：

LAR-LFR≤RWS 

 

当一个确认到达时，发送方向右移动L A R，从而允许发送方发送另一帧。同时，发送方为所发的每个帧设置一个定时器，如果定时器在A C K到达之前超时，则重发此帧。注意：发送方必须存储最多S W S个帧，因为在它们得到确认之前必须准备重发。

接收方维护下面3个变量：接收窗口大小（receive window size），记为RW S，给出接收方所能接收的无序帧数目的上界； L A F表示可接收帧（l a rgestacceptable frame）的序号；L F R表示最近收到的帧（last frame re ce i v e d）的序号。接收方也维持如下不变式：

LFS-LAR≤SWS 

 

当一个具有顺序号S e q N u m的帧到达时，接收方采取如下行动：如果S e q N u m≤L F R或S e q N u m > L A F，那么帧不在接收窗口内，于是被丢弃；如果L F R＜Se q N u m≤L A F，那么帧在接收窗口内，于是被接收。现在接收方需要决定是否发送一个A C K。设S e q N u m To A C K表示未被确认帧的最大序号，则序号小于或等于S e q N u m To Ac k的帧都已收到。即使已经收到更高序号的分组，接收方仍确认S e q N u m To A c k的接收。这种确认被称为是累积的（c u m u l a t i v e）。然后它设置L F R = S e q Nu m To A c k，并调整L A F = L F R + RW S。例如，假设L F R= 5（即，上次接收方发送的A C K是为了确认顺序号5的），并且RWS = 4。这意味着L A F = 9。如果帧7和8到达，则存储它们，因为它们在接收窗口内。然而并不需要发送A C K，因为帧6还没有到达。帧7和8被称为是错序到达的。（从技术上讲，接收方可以在帧7和8到达时重发帧5的A C K。）如果帧6当时到达了（或许它在第一次丢失后又重发从而晚到，或许它只是被延迟了），接收方确认帧8，L F R置为8，L A F置为1 2。如果实际上帧6丢失了，则出现发送方超时，重发帧6。我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。这意味着分组丢失时，此方案将不再保证管道满载。注意：分组丢失时间越长，这个问题越严重。
注意，在这个例子中，接收方可以在帧7刚一到达时就为帧6发送一个认帧N A K（negative acknowledgment）。然而，由于发送方的超时机制足以发现这种情况，发送N A K反而为发送方增加了复杂性，因此不必这样做。正如我们已提到的，当帧7和8到达时为帧5发送一个额外的A C K是合理的；在某些情况下，发送方可以使用重复的A C K作为一个帧丢失的线索。这两种方法都允许早期的分组丢失检测，有助于改进性能。
关于这个方案的另一个变种是使用选择确认（selective acknowledgements）。即，接收方能够准确地确认那些已收到的帧，而不只是确认按顺序收到最高序号的帧。因此，在上例中，接收方能够确认帧7、8的接收。如果给发送方更多的信息，就能使其较容易地保持管道满载，但增加了实现的复杂性。

发送窗口大小是根据一段给定时间内链路上有多少待确认的帧来选择的；对于一个给定的延迟与带宽的乘积，S W S是容易计算的。另一方面，接收方可以将RW S设置为任何想要的值。通常的两种设置是：RW S= 1，表示接收方不存储任何错序到达的帧； RW S=S W S，表示接收方能够缓存发送方传输的任何帧。由于错序到达的帧的数目不可能超过S W S个，所以设置RWS >S W S没有意义。

2. 有限顺序号和滑动窗口

---

现在我们再来讨论算法中做过的一个简化，即假设序号是可以无限增大的。当然，实际上是在一个有限的头部字段中说明一个帧的序号。例如，一个3比特字段意味着有8个可用序号0 ~ 7。因此序号必须可重用，或者说序号能回绕。这就带来了一个问题：要能够区别同一序号的不同次发送实例，这意味着可用序号的数目必须大于所允许的待确认帧的数目。例如，停止等待算法允许一次有1个待确认帧，并有2个不同的序号。
假设序号空间中的序号数比待确认的帧数大1，即S W S ≤ M A a xS e q N u m -1 ，其中M a x Seq N u m 是可用序号数。这就够了吗？答案取决于RW S 。如果RW S = 1，那么MaxSeqNum≥SWS+1是足够了。如果RW S等于S W S，那么有一个只比发送窗口尺寸大1的M a x S e q N u m是不够的。为看清这一点，考虑有8个序号0 ~ 7的情况，并且S W S = RW S = 7。假设发送方传输帧0 ~ 6，并且接收方成功接收，但A C K丢失。接收方现在希望接收帧7，0 ~ 5，但发送方超时，然后发送帧0 ~ 6。不幸的是，接收方期待的是第二次的帧0 ~ 5，得到的却是第一次的帧0 ~ 5。这正是我们想避免的情况。
结果是，当RW S = S W S时，发送窗口的大小不能大于可用序号数的一半，或更准确地说，SWS<(Maxseqnum+1)/2直观地，这说明滑动窗口协议是在序号空间的两半之间变换，就像停止等待协议的序号是在0和1之间变换一样。唯一的区别是，它在序号空间的两半之间连续滑动而不是离散的变换。
注意，这条规则是特别针对RW S = S W S的。我们把确定适用于RW S和S W S的任意值的更一般的规则留做一个练习。还要注意，窗口的大小和序号空间之间的关系依赖于一个很明显以至于容易被忽略的假设，即帧在传输中不重新排序。这在直连的点到点链路上不能发生，因为在传输过程中一个帧不可能赶上另一个帧。然而，我们将在第5章看到用在一个不同环境中的滑动窗口算法，并且需要设计另一条规则。

 

3. 滑动窗口的实现

---

下面的例程说明我们如何实现滑动窗口算法的发送和接收的两个方面。该例程取自一个正在使用的协议，称为滑动窗口协议S W P（Sliding Window Pro t o c o l）。为了不涉及协议图中的邻近协议，我们用H L P（高层协议）表示S W P上层的协议，用L I N K（链路层协议）表示S W P下层的协议。我们先定义一对数据结构。首先，帧头部非常简单：它包含一个序号（ S e q N u m）和一个确认号（ A c k N u m）。它还包含一个标志（ F l a g s）字段，表明帧是一个A C K帧还是携带数据的帧。

其次，滑动窗口算法的状态有如下结构。对于协议发送方，该状态包括如上所述的变量L A R和L F S，以及一个存放已发出但尚未确认的帧的队列（ s e n d Q）。发送方状态还包含一个计数信号量（ counting semaphore），称为s e n d Wi n d o w N o t F u l l。下面我们将会看到如何使用它，但一般来说，信号量是一个支持s e m Wa i t和s e m S i g n a l操作的同步原语。每次调用S e m S i g n al，信号量加1，每次调用S e m Wa i t，信号量减1。如果信号量减小，导致它的值小于0，那么调用进程阻塞（挂起）。一旦执行了足够的s e m S i g n a l操作而使信号量的值增大到大于0，在调用s e m Wa i t的过程中阻塞的进程就允许被恢复。
对于协议的接收方，如前所述，该状态包含变量L F R ，加上一个存放已收到的错序帧的队列（r e c v Q）。最后，虽然未显示，发送方和接收方的滑动窗口的大小分别由常量S W S和RW S表示。

S W P的发送方是由s e n d S W P过程实现的。这个例程很简单。首先， s e m Wa i t使这个进程在一个信号量上阻塞，直到它可以发另一帧。一旦允许继续， s e n d S W P设置帧头部中的顺序号，将此帧的拷贝存储在发送队列（s e n d Q）中，调度一个超时事件以便处理帧未被确认的情况，并将帧发给低层协议。

值得注意的一个细节是刚好在调用m s g A d d H dr之前调用s t o r e _ s w p _ h d r。该例程将存有S W P头部的C语言结构（ s t a t e -> h d r）转化为能够安全放在消息前面的字节串（ h b u f）。该例程（未给出）必须将头部中的每一个整数字段转化为网络字节顺序，并且去掉编译程序加入C语言结构中的任意填充。7 . 1节将详细讨论字节顺序的问题，但现在，假设该例程将多字整数中最高有效位放在最高地址字节就足够了。
这个例程的另一个复杂性是使用s e m Wa i t 和s e n dW i n d ow N o t F u l l 信号量。S e n dWi n d o w N o t F u l l被初始化为发送方滑动窗口的大小S W S（未给出这一初始化）。发送方每传输一帧， s e m Wa i t操作将这个数减1，如果减小到0，则阻塞发送方进程。每收到一个A C K，在d e l i v e r SW P中调用s e m S i g n a l操作（见下面）将此数加1，从而激活正在等待的发送方进程。

在继续介绍S W P的接收方之前，需要调整一个看上去不一致的地方。一方面，我们说过，高层协议通过调用s e n d操作来请求低层协议的服务，所以我们就希望通过S W P发送消息的协议能够调用s e n d（S W P, p a c k e t）。另一方面，用来实现S W P的发送操作的过程叫做s e n d S W P，并且它的第一个参数是一个状态变量（ S w p S t a t e）。结果怎样呢？答案是，操作系统提供了粘结代码将对s e n d的一般调用转化为对s e n d S W P的特定协议调用的粘结代码。这个粘结代码将s e n d的第一个参数（协议变量S W P）映射为一个指向s e n d S W P的函数指针和一个指向S W P工作时所需的协议状态的指针。我们之所以通过一般函数调用使高层协议间接调用特定协议函数，是因为我们想限制高层协议中对低层协议编码的信息量。这使得将来能够比较容易地改变协议图的配置。现在来看d e l i v e r操作的S W P的特定协议实现，它在过程d e l i v e r SW P中实现。这个例程实际上处理两种不同类型的输入消息：本结点已发出帧的A C K和到达这个结点的数据帧。在某种意义上，这个例程的ACK部分是与send SWP中所给算法的发送方相对应的。通过检验头部的F l a g s字段可以确定输入的消息是ACK还是一个数据帧。注意，这种特殊的实现不支持数据帧中捎带A C K。当输入帧是一个ACK时，delive rSWP仅仅在发送队列（send Q）中找到与此ACK相应的位置（slot），取消超时事件，并且释放保存在那一位置的帧。由于A C K可能是累积的，所以这项工作实际上是在一个循环中进行的。对于这种情况值得注意的另一个问题是子例程swp In Wind o w的调用。这个子例程在下面给出，它确保被确认帧的序号是在发送方当前希望收到的A C K的范围之内。
当输入帧包含数据时， d e l i v e r S W P首先调用m s g S t r i pH d r和l o a d _ s w p _ h d r以便从帧中提取头部。例程l o a d _ s w p_ h d r对应着前面讨论的s t o r e _ s w p _ h d r，它将一个字节串转化为容纳S W P头部的C语言数据结构。然后d e l i v e r SW P调用s w p I n Wi n d o w以确保帧序号在期望的序号范围内。如果是这样，例程在已收到的连续的帧的集合上循环，并通过调用d e l i v e r HL P例程将它们传给上层协议。它也要向发送方发送累积的A C K，但却是通过在接收队列上循环来实现的（它没有使用本节前面给出的s e q N u m To Ac k变量）。

 

最后，s w p I n Window是一个简单的子例程，它检查一个给定的序号是否落在某个最大和最小顺序号之间。

 

4. 帧顺序和流量控制

---

滑动窗口协议可能是计算机网络中最著名的算法。然而，关于该算法易产生混淆的是，它可以有三个不同的功能，第一个功能是本节的重点，即在不可靠链路上可靠地传输帧。（一般来说，该算法被用于在一个不可靠的网络上可靠地传输消息。）这是该算法的核心功能。

滑动窗口算法的第二个功能是用于保持帧的传输顺序。这在接收方比较容易实现，因为每个帧有一个序号，接收方要保证已经向上层协议传递了所有序号比当前帧小的帧，才向上传送该当前帧。即，接收方缓存了（即没有传送）错序的帧。本节描述的滑动窗口算法确实保持了帧的顺序，尽管我们可以想象一个变异，即接收方没有等待更早传送的帧都到达就将帧传给下一个协议。我们可以提出的一个问题是：我们是否确实需要滑动窗口协议来保持帧的顺序，或者，这样的功能在链路层是否是不必要的。不幸的是，我们还没有看到足够多的网络体系结构来回答这个问题我们首先需要理解的是，点到点链路序列如何由交换机连接而形成一条端到端的路径。
滑动窗口算法的第三个功能是，它有时支持流量控制（f l o w c o n t ro l），它是一种接收方能够控制发送方使其降低速度的反馈机制。这种机制用于抑制发送方发送速度过快，即抑制传输比接收方所能处理的更多的数据。这通常通过扩展滑动窗口协议完成，使接收方不仅确认收到的帧，而且通知发送方它还可接收多少帧。可接收的帧数对应着接收方空闲的缓冲区数。在按序传递的情况下，在将流量控制并入滑动窗口协议之前，我们应该确信流量控制在链路层是必要的。
尚未讨论的一个重要概念是系统设计原理，我们称其为相关性分离（separation of concerns）。即，你必须小心区别有时交织在一种机制中的不同功能，并且你必须确定每一个功能是必要的，而且是被最有效的方式支持的。在这种特定的情况下，可靠传输、按序传输和流量控制有时组合在一个滑动窗口协议里，我们应该问问自己，在链路层这样做是否正确。带着这样的疑问，我们将在第3章（说明X. 2 5网如何用它实现跳到跳的流量控制）和第5章（描述T C P如何用它实现可靠的字节流信道）重新考虑滑动窗口算法。

tcp和udp的区别

TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。
UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快

现在Internet上流行的协议是TCP/IP协议，该协议中对低于1024的端口都有确切的定义，他们对应着Internet上一些常见的服务。这些常见的服务可以分为使用TCP端口（面向连接）和使用UDP端口（面向无连接）两种。

TIME_WAIT出现在哪里，为什么

1、 time_wait的作用：

TIME_WAIT状态存在的理由：
1）可靠地实现TCP全双工连接的终止
   在进行关闭连接四次挥手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN，
因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在。
因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。
 
2）允许老的重复分节在网络中消逝 
TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。
在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。
为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝。

2.time_wait状态如何产生？ 

首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL值得是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用。

3、大量TIME_WAIT造成的影响：

      在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。

为什么我们要关注这个高并发短连接呢？有两个方面需要注意：
1. 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
2. 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。

      这里有个相对长短的概念，比如取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高。
     综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题。

关于time_wait的反思：

存在即是合理的，既然TCP协议能盛行四十多年，就证明他的设计合理性。所以我们尽可能的使用其原本功能。
依靠TIME_WAIT状态来保证我的服务器程序健壮，服务功能正常。
那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候，我的原则是尽量处理，而不是跟TIMEWAIT干上，非先除之而后快。
如果尽量处理了，还是解决不了问题，仍然拒绝服务部分请求，那我会采取负载均衡来抗这些高并发的短请求。持续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到时才需要关注这个问题的访问量。

4.time_wait状态如何避免

（1）首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。

（2）由于time_wait状态是在主动关闭的一方出现的，所以在设计协议逻辑的时候，尽量由客户端主动关闭，避免服务端出现time_wait

（3）so_linger设置 l_onoff为非0，l_linger为0，则套接口关闭时TCP夭折连接，TCP将丢弃保留在套接口发送缓冲区中的任何数据并发送一个RST给对方，而不是通常的四分组终止序列，这避免了TIME_WAIT状态；

注意：time_wait 能保障我们服务的健壮性，所以尽量避免使用上叙手段

ping的原理

ping其实属于一个通信协议，是TCP/IP协议的一部分；Ping发送一个ICMP也就是因特网信报控制协议；发消息给目的地并报告是否收到所希望的ICMP echo（ICMP回声应答）。是用来检查网络是否通畅或者网络连接速度的命令；原理如下：利用网络机器IP地址的唯一性，给目标IP地址发送一个数据包，再要求对方返回一个同样大小的数据包来确定两台网络机器是否连接相通，时延是多少。应用格式：ping IP地址；

ARP原理

思路

1、思考ARP到底是干嘛的？ 为什么要有它？why？  

2、掌握ARP的工作原理。

技术人，要掌握一种技术，绝对离不开以上两点基本思路，带着这两个思路去学习新技术，你绝对是不可能学不会的。再笨，你也会学得很深刻的。甚至，你还可以有更多的思路，比如，可不可以没有它？ 有它？跟没有它的情况又是什么样的？等等。

1、ARP到底是干嘛的？

我们都知道局域网里面通信，都是靠MAC地址来通信的。ARP简单说，就是用来把IP地址转换成MAC地址，就是某个去往目的IP地址翻译成MAC地址。

交换机的工作原理就是基于源MAC地址学习，基于目的MAC地址转发的。大家都知道网络的参考模型，我们在电脑上要发送消息时，电脑内部的处理机制是先从上层开始一层一层往下封装的。如图:

现在，有了这张图，就更容易理解ARP的作用了。

电脑从上层往下封装，到了二层，要封装帧头部时，就需要把目的mac地址封装上，形成完整的二层头部后，就可以发送出去了。

 

现在的问题就是，电脑如何知道对方的MAC地址？

 

计算机A要发送消息，给计算机E。他们是第一次通信。

 

当用户计算机A在上使用QQ聊天工具，输入：你好，约吗？

回车，计算机A就先从上层往下封装头部。如IP头部就将

目的IP：1.1.1.2   ， 源IP就是：1.1.1.1 等信息进行封装，到了二层，就需要将目的MAC地址，源MAC地址进行封装。计算机A肯定知道自己网卡的mac地址，为1111.1111.1111.1111。但是目的mac地址（计算机E的mac地址）就不知道了，因为他们是第一次通信，哪里知道啊~  要是知道，就上天了！

于是，这时候，计算机A就执行ARP程序，发送一个ARP请求报文的广播包：

该数据包的关键字段如下：

---

二层：

目的MAC地址：ffff.ffff.ffff.ffff

源mac地址：1111.1111.1111.1111

类型：0x0806

arp的关键内容如下：

source mac：1111.1111.1111.1111.1111

source IP： 1.1.1.1

target mac：ffff.ffff.ffff.ffff （因为第一次通信，不知道对方的mac地址）

target IP：1.1.1.2

这样，交换机收到这个报文，看到目的mac地址是全F就进广播！

阿龙这里要提醒初学者的是，因为交换机是二层设备，只会拆包、解析到二层信息而已，不会进行更深入的解析，如网络层信息。换句话说，就是交换机根本不知道里面是什么数据，只知道这个数据包的源、目mac地址而已。

这样，所有的计算机收到这个广播包，会进行更深入的解析，看到里面的target IP 是1.1.1.2,  与自己的IP地址进行对比，发现不一样，就丢弃。发现一样，就回应ARP报文。单播回应喔！

 

ARP的响应报文里的关键字段如下，

---

二层：

目的MAC地址：1111.1111.1111.1111

源mac地址：2222.2222.2222.2222

类型：0x0806

arp的关键内容如下：

source mac：2222.2222.2222.2222

source IP： 1.1.1.1

target mac：1111.1111.1111.1111 （从请求包里得知A的mac地址，于是单播）

target IP：1.1.1.1

---

 

这样，计算机A收到这个报文后，就将计算机E的mac地址记录下来，存在计算机A的一个数据库，叫做ARP缓存表。下次通信时，如果缓存未超时，就可以直接使用了。如果超时了，就再次进行arp请求广播了。

如果你还不信的话，那龙哥就亲自动手做实验吧！  

 

计算机A的信息：

 

计算机E的信息：

 

用计算机A ping 计算机E来模拟A发送消息给计算机E，并且抓包：

 

抓包就会发现抓到了2个ARP的报文：

分别如下：

1、

 

2、

 

这时，你就可以在计算机A看到arp缓存表了：

http和https

什么是 HTTPS?

HTTPS (基于安全套接字层的超文本传输协议 或者是 HTTP over SSL) 是一个 Netscape 开发的 Web 协议。

你也可以说：HTTPS = HTTP + SSL

HTTPS 在 HTTP 应用层的基础上使用安全套接字层作为子层。

为什么需要 HTTPS ？

超文本传输协议 (HTTP) 是一个用来通过互联网传输和接收信息的协议。HTTP 使用请求/响应的过程，因此信息可在服务器间快速、轻松而且精确的进行传输。当你访问 Web 页面的时候你就是在使用 HTTP 协议，但 HTTP 是不安全的，可以轻松对窃听你跟 Web 服务器之间的数据传输。在很多情况下，客户和服务器之间传输的是敏感歇息，需要防止未经授权的访问。为了满足这个要求，网景公司(Netscape)推出了HTTPS，也就是基于安全套接字层的 HTTP 协议。

HTTP 和 HTTPS 的相同点

大多数情况下，HTTP 和 HTTPS 是相同的，因为都是采用同一个基础的协议，作为 HTTP 或 HTTPS 客户端——浏览器，设立一个连接到 Web 服务器指定的端口。当服务器接收到请求，它会返回一个状态码以及消息，这个回应可能是请求信息、或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式，因此资源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。

HTTP 和 HTTPS 的不同之处

1. HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
4. 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
5. HTTP 无需加密，而 HTTPS 对传输的数据进行加密
6. HTTP 无需证书，而 HTTPS 需要认证证书

HTTPS 如何工作?

使用 HTTPS 连接时，服务器要求有公钥和签名的证书。

当使用 https 连接，服务器响应初始连接，并提供它所支持的加密方法。作为回应，客户端选择一个连接方法，并且客户端和服务器端交换证书验证彼此身份。完成之后，在确保使用相同密钥的情况下传输加密信息，然后关闭连接。为了提供 https 连接支持，服务器必须有一个公钥证书，该证书包含经过证书机构认证的密钥信息，大部分证书都是通过第三方机构授权的，以保证证书是安全的。

换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：

1. 浏览器打开一个 TCP 连接
2. 浏览器发送 HTTP 请求到服务器端
3. 服务器发送 HTTP 回应信息到浏览器
4. TCP 连接关闭

SSL 包含如下动作：

1. 验证服务器端
2. 允许客户端和服务器端选择加密算法和密码，确保双方都支持
3. 验证客户端(可选)
4. 使用公钥加密技术来生成共享加密数据
5. 创建一个加密的 SSL 连接
6. 基于该 SSL 连接传递 HTTP 请求

什么时候该使用 HTTPS?

银行网站、支付网关、购物网站、登录页、电子邮件以及一些企业部门的网站应该使用 HTTPS，例如：

• PayPal: https://www.paypal.com
• Google AdSense: https://www.google.com/adsense/

如果某个网站要求你填写信用卡信息，首先你要检查该网页是否使用 https 加密连接，如果没有，那么请不要输入任何敏感信息如信用卡号。

常用加密算法

常用加密算法概述

常见的加密算法可以分成三类，对称加密算法，非对称加密算法和Hash算法。

对称加密

    指加密和解密使用相同密钥的加密算法。对称加密算法的优点在于加解密的高速度和使用长密钥时的难破解性。假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。对称加密算法的安全性取决于加密密钥的保存情况，但要求企业中每一个持有密钥的人都保守秘密是不可能的，他们通常会有意无意的把密钥泄漏出去——如果一个用户使用的密钥被入侵者所获得，入侵者便可以读取该用户密钥加密的所有文档，如果整个企业共用一个加密密钥，那整个企业文档的保密性便无从谈起。

常见的对称加密算法：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES

 

非对称加密

    指加密和解密使用不同密钥的加密算法，也称为公私钥加密。假设两个用户要加密交换数据，双方交换公钥，使用时一方用对方的公钥加密，另一方即可用自己的私钥解密。如果企业中有n个用户，企业需要生成n对密钥，并分发n个公钥。由于公钥是可以公开的，用户只要保管好自己的私钥即可，因此加密密钥的分发将变得十分简单。同时，由于每个用户的私钥是唯一的，其他用户除了可以可以通过信息发送者的公钥来验证信息的来源是否真实，还可以确保发送者无法否认曾发送过该信息。非对称加密的缺点是加解密速度要远远慢于对称加密，在某些极端情况下，甚至能比非对称加密慢上1000倍。

常见的非对称加密算法：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

 

Hash算法

    Hash算法特别的地方在于它是一种单向算法，用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值，却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

常见的Hash算法：MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1

 

    加密算法的效能通常可以按照算法本身的复杂程度、密钥长度（密钥越长越安全）、加解密速度等来衡量。上述的算法中，除了DES密钥长度不够、MD2速度较慢已逐渐被淘汰外，其他算法仍在目前的加密系统产品中使用。

 

加密算法的选择

    前面的章节已经介绍了对称解密算法和非对称加密算法，有很多人疑惑：那我们在实际使用的过程中究竟该使用哪一种比较好呢？

    我们应该根据自己的使用特点来确定，由于非对称加密算法的运行速度比对称加密算法的速度慢很多，当我们需要加密大量的数据时，建议采用对称加密算法，提高加解密速度。

对称加密算法不能实现签名，因此签名只能非对称算法。

由于对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着他的安全性，因此当数据量很小时，我们可以考虑采用非对称加密算法。

    在实际的操作过程中，我们通常采用的方式是：采用非对称加密算法管理对称算法的密钥，然后用对称加密算法加密数据，这样我们就集成了两类加密算法的优点，既实现了加密速度快的优点，又实现了安全方便管理密钥的优点。

    如果在选定了加密算法后，那采用多少位的密钥呢？一般来说，密钥越长，运行的速度就越慢，应该根据的我们实际需要的安全级别来选择，一般来说，RSA建议采用1024位的数字，ECC建议采用160位，AES采用128为即可。

 

 

二.          加密算法介绍

对称加密算法

对称加密算法用来对敏感数据等信息进行加密，常用的算法包括：

DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。

3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。

AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；

AES与3DES的比较

算法名称	算法类型	密钥长度	速度	解密时间（建设机器每秒尝试255个密钥）	资源消耗
AES	对称block密码	128、192、256位	高	1490000亿年	低
3DES	对称feistel密码	112位或168位	低	46亿年	中

非对称算法

RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的；

DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）；

ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。

ECC和RSA相比，在许多方面都有对绝对的优势，主要体现在以下方面：

抗攻击性强。相同的密钥长度，其抗攻击性要强很多倍。

计算量小，处理速度快。ECC总的速度比RSA、DSA要快得多。

存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多，意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。

带宽要求低。当对长消息进行加解密时，三类密码系统有相同的带宽要求，但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。

下面两张表示是RSA和ECC的安全性和速度的比较。

攻破时间(MIPS年)	RSA/DSA(密钥长度)	ECC密钥长度	RSA/ECC密钥长度比
104	512	106	5：1
108	768	132	6：1
1011	1024	160	7：1
1020	2048	210	10：1
1078	21000	600	35：1

攻破时间(MIPS年)	RSA/DSA(密钥长度)	ECC密钥长度	RSA/ECC密钥长度比
104	512	106	5：1
108	768	132	6：1
1011	1024	160	7：1
1020	2048	210	10：1
1078	21000	600	35：1

RSA和ECC安全模长得比较

功能	Security Builder 1.2	BSAFE 3.0
	163位ECC(ms)	1,023位RSA(ms)
密钥对生成	3.8	4,708.3
签名	2.1(ECNRA)	228.4
	3.0(ECDSA)
认证	9.9(ECNRA)	12.7
	10.7(ECDSA)
Diffie—Hellman密钥交换	7.3	1,654.0

RSA和ECC速度比较

散列算法

散列是信息的提炼，通常其长度要比信息小得多，且为一个固定长度。加密性强的散列一定是不可逆的，这就意味着通过散列结果，无法推出任何部分的原始信息。任何输入信息的变化，哪怕仅一位，都将导致散列结果的明显变化，这称之为雪崩效应。散列还应该是防冲突的，即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。

单向散列函数一般用于产生消息摘要，密钥加密等，常见的有：

l         MD5（Message Digest Algorithm 5）：是RSA数据安全公司开发的一种单向散列算法，非可逆，相同的明文产生相同的密文。

l         SHA（Secure Hash Algorithm）：可以对任意长度的数据运算生成一个160位的数值；

SHA-1与MD5的比较

因为二者均由MD4导出，SHA-1和MD5彼此很相似。相应的，他们的强度和其他特性也是相似，但还有以下几点不同：

l         对强行供给的安全性：最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术，产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作，而对SHA-1则是2160数量级的操作。这样，SHA-1对强行攻击有更大的强度。

l         对密码分析的安全性：由于MD5的设计，易受密码分析的攻击，SHA-1显得不易受这样的攻击。

l         速度：在相同的硬件上，SHA-1的运行速度比MD5慢。

对称与非对称算法比较

    以上综述了两种加密方法的原理，总体来说主要有下面几个方面的不同：

l         在管理方面：公钥密码算法只需要较少的资源就可以实现目的，在密钥的分配上，两者之间相差一个指数级别（一个是n一个是n2）。所以私钥密码算法不适应广域网的使用，而且更重要的一点是它不支持数字签名。

l         在安全方面：由于公钥密码算法基于未解决的数学难题，在破解上几乎不可能。对于私钥密码算法，到了AES虽说从理论来说是不可能破解的，但从计算机的发展角度来看。公钥更具有优越性。

l         从速度上来看：AES的软件实现速度已经达到了每秒数兆或数十兆比特。是公钥的100倍，如果用硬件来实现的话这个比值将扩大到1000倍。

三.            加密算法的选择

由于非对称加密算法的运行速度比对称加密算法的速度慢很多，当我们需要加密大量的数据时，建议采用对称加密算法，提高加解密速度。

对称加密算法不能实现签名，因此签名只能非对称算法。

由于对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着他的安全性，因此当数据量很小时，我们可以考虑采用非对称加密算法。

在实际的操作过程中，我们通常采用的方式是：采用非对称加密算法管理对称算法的密钥，然后用对称加密算法加密数据，这样我们就集成了两类加密算法的优点，既实现了加密速度快的优点，又实现了安全方便管理密钥的优点。

那采用多少位的密钥呢？ RSA建议采用1024位的数字，ECC建议采用160位，AES采用128为即可。

四.            密码学在现代的应用

保密通信：保密通信是密码学产生的动因。使用公私钥密码体制进行保密通信时，信息接收者只有知道对应的密钥才可以解密该信息。

数字签名：数字签名技术可以代替传统的手写签名，而且从安全的角度考虑，数字签名具有很好的防伪造功能。在政府机关、军事领域、商业领域有广泛的应用环境。

秘密共享：秘密共享技术是指将一个秘密信息利用密码技术分拆成n个称为共享因子的信息，分发给n个成员，只有k(k≤n)个合法成员的共享因子才可以恢复该秘密信息，其中任何一个或m(m≤k)个成员合作都不知道该秘密信息。利用秘密共享技术可以控制任何需要多个人共同控制的秘密信息、命令等。

认证功能：在公开的信道上进行敏感信息的传输，采用签名技术实现对消息的真实性、完整性进行验证，通过验证公钥证书实现对通信主体的身份验证。

密钥管理：密钥是保密系统中更为脆弱而重要的环节，公钥密码体制是解决密钥管理工作的有力工具；利用公钥密码体制进行密钥协商和产生，保密通信双方不需要事先共享秘密信息；利用公钥密码体制进行密钥分发、保护、密钥托管、密钥恢复等。

基于公钥密码体制可以实现以上通用功能以外，还可以设计实现以下的系统：安全电子商务系统、电子现金系统、电子选举系统、电子招投标系统、电子彩票系统等。

 

一. AES对称加密:

                                                      AES加密



                         分组

 

 

二. 分组密码的填充

                                                   分组密码的填充

 

e.g.:

                                                         PKCS#5填充方式

 

 

 

三. 流密码:

 

 

 

四. 分组密码加密中的四种模式:

3.1 ECB模式

优点:

1.简单；

2.有利于并行计算；

3.误差不会被传送；

缺点:

1.不能隐藏明文的模式；

2.可能对明文进行主动攻击；

 

3.2 CBC模式：

优点：

1.不容易主动攻击,安全性好于ECB,适合传输长度长的报文,是SSL、IPSec的标准。

缺点：

1.不利于并行计算；

2.误差传递；

3.需要初始化向量IV

 

3.3 CFB模式：

 优点：

1.隐藏了明文模式;

2.分组密码转化为流模式;

3.可以及时加密传送小于分组的数据;

缺点:

1.不利于并行计算;

2.误差传送：一个明文单元损坏影响多个单元;

3.唯一的IV;

 

3.4 OFB模式：

 优点:

1.隐藏了明文模式;

2.分组密码转化为流模式;

3.可以及时加密传送小于分组的数据;

缺点:

1.不利于并行计算;

2.对明文的主动攻击是可能的;

3.误差传送：一个明文单元损坏影响多个单元;

get和post的区别

GET和POST是HTTP请求的两种基本方法，要说它们的区别，接触过WEB开发的人都能说出一二。

最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。

你可能自己写过无数个GET和POST请求，或者已经看过很多权威网站总结出的他们的区别，你非常清楚知道什么时候该用什么。

当你在面试中被问到这个问题，你的内心充满了自信和喜悦。

你轻轻松松的给出了一个“标准答案”：
 

• GET在浏览器回退时是无害的，而POST会再次提交请求。

   

• GET产生的URL地址可以被Bookmark，而POST不可以。

   

• GET请求会被浏览器主动cache，而POST不会，除非手动设置。

   

• GET请求只能进行url编码，而POST支持多种编码方式。

   

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

   

• GET请求在URL中传送的参数是有长度限制的，而POST么有。

   

• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

   

• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

   

• GET参数通过URL传递，POST放在Request body中。

•  

“很遗憾，这不是我们要的回答！”

请告诉我真相。。。

如果我告诉你GET和POST本质上没有区别你信吗？ 
让我们扒下GET和POST的外衣，坦诚相见吧！

GET和POST是什么？HTTP协议中的两种发送请求的方法。

HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。

 

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。 

 

那么，“标准答案”里的那些区别是怎么回事？

 

在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。

 

但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？

在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。

 

好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。 

 

你以为本文就这么结束了？

我们的大BOSS还等着出场呢。。。

这位BOSS有多神秘？当你试图在网上找“GET和POST的区别”的时候，那些你会看到的搜索结果里，从没有提到他。他究竟是什么呢。。。

 

GET和POST还有一个重大区别，简单的说：

GET产生一个TCP数据包；POST产生两个TCP数据包。

 

长的说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

 

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

 

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？

1. GET与POST都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

AIO NIO BIO

一：事件分离器

        在IO读写时，把 IO请求 与 读写操作 分离调配进行，需要用到事件分离器。根据处理机制的不同，事件分离器又分为：同步的Reactor和异步的Proactor。

        Reactor模型：

    - 应用程序在事件分离器注册 读就绪事件 和 读就绪事件处理器
    - 事件分离器等待读就绪事件发生
    - 读就绪事件发生，激活事件分离器，分离器调用 读就绪事件处理器（即：可以进行读操作了，开始读）
    - 读事件处理器开始进行读操作，把读到的数据提供给程序使用

        Proactor模型：

      - 应用程序在事件分离器注册 读完成事件 和 读完成事件处理器，并向操作系统发出异步读请求

   - 事件分离器等待操作系统完成读取

   - 在分离器等待过程中，操作系统利用并行的内核线程执行实际的读操作，并将结果数据存入用户自定义缓冲区，最后通知事件分离器读操作完成

   - 事件分离器监听到 读完成事件 后，激活 读完成事件的处理器

   - 读完成事件处理器 处理用户自定义缓冲区中的数据给应用程序使用

    

       同步和异步的区别就在于 读 操作由谁完成：同步的Reactor是指程序发出读请求后，由分离器监听到可以进行读操作时（需要获得读操作条件）通知事件处理器进行读操作，异步的Proactor是指程序发出读请求后，操作系统立刻异步地进行读操作了，读完之后在通知分离器，分离器激活处理器直接取用已读到的数据。

      

        二：同步阻塞IO（BIO）

        我们熟知的Socket编程就是BIO，一个socket连接一个处理线程（这个线程负责这个Socket连接的一系列数据传输操作）。阻塞的原因在于：操作系统允许的线程数量是有限的，多个socket申请与服务端建立连接时，服务端不能提供相应数量的处理线程，没有分配到处理线程的连接就会阻塞等待或被拒绝。

 

         三：同步非阻塞IO（NIO）

         New IO是对BIO的改进，基于Reactor模型。我们知道，一个socket连接只有在特点时候才会发生数据传输IO操作，大部分时间这个“数据通道”是空闲的，但还是占用着线程。NIO作出的改进就是“一个请求一个线程”，在连接到服务端的众多socket中，只有需要进行IO操作的才能获取服务端的处理线程进行IO。这样就不会因为线程不够用而限制了socket的接入。客户端的socket连接到服务端时，就会在事件分离器注册一个 IO请求事件 和 IO 事件处理器。在该连接发生IO请求时，IO事件处理器就会启动一个线程来处理这个IO请求，不断尝试获取系统的IO的使用权限，一旦成功（即：可以进行IO），则通知这个socket进行IO数据传输。

         NIO还提供了两个新概念：Buffer和Channel

Buffer:
–        是一块连续的内存块。
–        是 NIO 数据读或写的中转地。
Channel:
–        数据的源头或者数据的目的地
–        用于向 buffer 提供数据或者读取 buffer 数据 ,buffer 对象的唯一接口。
–         异步 I/O 支持
      Buffer作为IO流中数据的缓冲区，而Channel则作为socket的IO流与Buffer的传输通道。客户端socket与服务端socket之间的IO传输不直接把数据交给CPU使用，
而是先经过Channel通道把数据保存到Buffer，然后CPU直接从Buffer区读写数据，一次可以读写更多的内容。
      使用Buffer提高IO效率的原因（这里与IO流里面的BufferedXXStream、BufferedReader、BufferedWriter提高性能的原理一样）：IO的耗时主要花在数据传输的路上，普通的IO是一个字节一个字节地传输，
而采用了Buffer的话，通过Buffer封装的方法（比如一次读一行，则以行为单位传输而不是一个字节一次进行传输）就可以实现“一大块字节”的传输。比如：IO就是送快递，普通IO是一个快递跑一趟，采用了Buffer的IO就是一车跑一趟。很明显，buffer效率更高，花在传输路上
的时间大大缩短。

 

          四：异步阻塞IO（AIO）

          NIO是同步的IO，是因为程序需要IO操作时，必须获得了IO权限后亲自进行IO操作才能进行下一步操作。AIO是对NIO的改进（所以AIO又叫NIO.2），它是基于Proactor模型的。每个socket连接在事件分离器注册 IO完成事件 和 IO完成事件处理器。程序需要进行IO时，向分离器发出IO请求并把所用的Buffer区域告知分离器，分离器通知操作系统进行IO操作，操作系统自己不断尝试获取IO权限并进行IO操作（数据保存在Buffer区），操作完成后通知分离器；分离器检测到 IO完成事件，则激活 IO完成事件处理器，处理器会通知程序说“IO已完成”，程序知道后就直接从Buffer区进行数据的读写。

          也就是说：AIO是发出IO请求后，由操作系统自己去获取IO权限并进行IO操作；NIO则是发出IO请求后，由线程不断尝试获取IO权限，获取到后通知应用程序自己进行IO操作。

select poll epoll

  目前支持I/O多路复用的系统调用有 select，pselect，poll，epoll，I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，pselect，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

     与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小，系统不必创建进程/线程，也不必维护这些进程/线程，从而大大减小了系统的开销。

 

一、使用场景

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。IO多路复用适用如下场合：

　　1）当客户处理多个描述符时（一般是交互式输入和网络套接口），必须使用I/O复用。

　　2）当一个客户同时处理多个套接口时，这种情况是可能的，但很少出现。

　　3）如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用到I/O复用。

　　4）如果一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用。

　　5）如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用。

 

二、select、poll、epoll简介

　　epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现。

1、select

基本原理：select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

 

基本流程，如图所示：

 

　　select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但是这样也会造成效率的降低。

 

select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

1、select最大的缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024。

　　一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.

2、对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低。

　　当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

3、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。

 

2、poll

基本原理：poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

 

它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：

1）大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。

2）poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

 

注意：从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

 

3、epoll

　　epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

 

基本原理：epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

 

epoll的优点：

1、没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。

2、效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。

　　只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。

3、内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

 

epoll对文件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别如下：

LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。

ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。

1、LT模式

　　LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的。

2、ET模式

　　ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)。

　　ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

3、在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制。这正是epoll的魅力所在。)

注意：如果没有大量的idle-connection或者dead-connection，epoll的效率并不会比select/poll高很多，但是当遇到大量的idle-connection，就会发现epoll的效率大大高于select/poll。

 

三、select、poll、epoll区别

1、支持一个进程所能打开的最大连接数

 

2、FD剧增后带来的IO效率问题

 

3、消息传递方式

 

 

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点：

1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善。

手撕代码

单例模式

二叉树按层打印

两个桟实现队列，两个队列实现桟

单链表反转

合并有序数组

合并链表

链表排序

打印菱形

字符串转整数

Linux相关：

常用命令

查看进程命令

查看端口

杀死进程

硬连接与软连接

定义全局变量

grep cut awk

查找命令

其他

cookie和session

Zookeeper的选举过程，协议

分布式事务，数据一致性

你了解哪些设计模式

servlet

如何解决Hash冲突

你看过哪些源码

平时如何学习的

Docker相关命令