第二周总结

第二周学习总结

时间：2019 年 01 月 07 日 ~ 2019 年 01 月 11 日

一、DCL 失效

class Tt {

    private static Tt instance;
    
    private Tt() {}
    
    public static Tt getInstance() {
        if (null == instance) {
            synchronized (Tt.class) {
                if (null == instance) {
                    instance = new Tt();
                }
            }
        }
        return instance;
    }
}

DCL 问题对应的现象是，在执行 instance == new Tt(); 时，这一句代码对应以下步骤：
① 分配对象的内存空间
② 初始化对象
③ 将 instance 指向刚刚分配的内存空间的内存地址
其中 ②、③ 的执行并不一定是顺序执行，编译器可能会对指令进行重排，即编译器允许对象在构造函数未调用完前, 将变量的引用指向构造的对象，在这种情况下，对象不为 null，然后对象还可能没有被初始化
由于 synchronized 关键字的存在，某个线程获取了锁，创建对象时可能存在上述情况，即引用不为 null，但是对象可能还没初始化，其它线程就会直接因为判断引用不为 null，直接返回引用，若通过此引用访问对象，就会出现异常

二、TCP 和 UDP，三次握手四次挥手

UDP：User Data Protocol，用户数据报协议，不可靠、无连接的传输协议

• 无连接、发送之前不需要建立连接
• 不保证可靠交付，不使用阻塞控制
• 面向报文，没有拥塞控制
• 支持一对一、一对多、多对一、多对多的交互通信
• 首部开销小（8 个字节）

UDP 首部
存储信息：
（1）源端口：即发送方的端口号，需要接收方回应时选用，不需要接收方回应时全填 0
（2）目的端口：接收方端口号
（3）长度：UDP 数据报长度，最小为 0（即只存在首部）
（4）校验和：校验 UDP 数据报在传输过程中是否出错，是则丢弃

UDP 首部组装完毕后，会将完整的数据报发送到网络层，跟 IP 数据报首部组成 IP 数据报再向上发送

TCP
TCP：Tranmission Control Protocol，传输控制协议，可靠的、面向连接传输协议

• 面向连接
• 每条 TCP 有且只有两个端点，一对一关系
• 提供可靠交互的服务
• 提供全双工通信（两边都能同时传输接收数据）
• 面向字节流

TCP 三次握手
第一次：建立连接，客户端发送连接请求，发送 SYN 报文段，SYN = 1，seq = x，然后进入 SYN_SENT 状态，等待服务端确认
第二次：服务端数到客户端的 SYN 报文段，对 SYN 报文段进行确认，ACK = 1，ack = x + 1，SYN = 1，seq = y，然后将该 SYN + ACK 报文段发送给客户端，之后进入 SYN_RCVD 状态
第三次：客户端收到服务端的 SYN + ACK 报文段，设置 ACK = 1，ack = y + 1，seq = x + 1，然后将该 ACK 报文段发送给服务端，该报文段发送完毕后，客户端和服务端都进入 ESTABLISHED（TCP 连接成功）状态，完成 TCP 三次握手

TCP 四次挥手
第一次：客户端要主动断开连接时，会发送 FIN 报文段，FIN = 1，seq = u，之后客户端进入 FIN_WAIT_1 状态，表示已没有数据发往服务端
第二次：服务端收到客户端的 FIN 报文段，给客户端回复了一个 ACK 报文段，ACK = 1，seq = v，ack = u + 1
第三次：服务端向客户端发送 FIN 报文段，FIN = 1，ACK = 1，seq = w，ack = u + 1，请求关闭连接
第四次：客户端收到服务端的 FIN 报文段，设置 ACK = 1，ack = w + 1，seq = u + 1，然后将该 ACK 报文段发送给服务端，该报文段发送完毕后，客户端进入 TIME_WAIT 状态，服务端收到客户端发来的 ACK 报文段后，就关闭连接，客户端在等待 2MSL（最大报文生存时间）后，如果没有收到任何回复，说明服务端已正常关闭，客户端也可以关闭连接了

三、流量控制、拥塞避免

流量控制
协调两端因处理数据速度不同所带来的问题
就是接收方让发送方发送数据时不要发的太快，一旦超出接收方的处理速度，就需要流量控制来调整发送方发送数据的速度，即接收方在返回的 ACK 中包含自己接受窗口的大小，利用该大小来控制发送方的数据发送

流量控制实现
① 滑动窗口不仅仅存在于发送方，同样也存在于接收方，接收方收到数据包后会将数据包放入滑动窗口，对数据包操作完毕后会将数据包从滑动窗口中移出，当接收方的滑动窗口填满了数据包时，不会再接收数据了，同时发送方窗口和接收方窗口大小是相同的，因此滑动窗口可以实现流量控制
② 发送方和接收方建立连接时，发送方会明确自己滑动窗口的大小，如果接收方窗口数据满了，数据处理不过来，那么可以通知发送方减小窗口大小

拥塞避免
就是数据堵在半路上

方式一（已废弃，出现拥塞后，滑动窗口从 1 开始）：首先将滑动窗口设置为 1，之后指数形式增加，当滑动窗口到达 ssthresh（慢开始门限），之后以加法形式增加，当出现拥塞现象时，就立即将滑动窗口设置为 1，ssthresh 在其上次值基础上以乘法形式减小，减小到滑动窗口出现拥塞时窗口的一半，之后反复前面过程，此过程称为慢恢复

方式二：出现拥塞之前，和方式一过程相同，当出现拥塞时，ssthresh 在其上次值基础上以乘法形式减小到某个值，减小到滑动窗口出现拥塞时窗口的一半，此时滑动窗口设置为该值，然后以加法形式增加，此过程称为快恢复

四、Java 集合…