面经

redis

redis是NOSQL，即非关系型数据库，也是缓存数据库，即将数据存储在缓存中，缓存的读取速度快，能够大大的提高运行效率；单线程操作，避免了频繁的上下文切换，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU；但是保存时间有限，当数据量超过内存空间时，需扩充内存，但内存价格贵。单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。

先安装好redis，然后运行，在pom文件中引入依赖，在要使用redis缓存的类的mapper.xml文件配置redis的全限定名。引入redis的redis.properties文件（如果要更改配置就可以使用）

如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。Redis集群有16384个哈希槽。根据公式HASH_SLOT=CRC16(key) mod 16384，CRC 16算法产生的hash值有16bit，该算法可以产生2^16-=65536个值。如果槽位为65536，发送的消息头达8k，发送的包过于庞大。

Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了事件，不在I/O上浪费过多的时间。

删除策略
如果假设你设置了一批 key 只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？定期删除（redis默认每个100ms检查，是否有过期的key，有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。）+惰性删除。
redis 提供 6种数据淘汰策略：
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
4.0版本后增加以下两种：
volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

主从复制 读写分离
大多数站点的数据库读操作比写操作更加密集，而且查询条件相对复杂，数据库的大部分性能消耗在查询操作上了。一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。主从复制数据是异步完成的，这就导致主从数据库中的数据有一定的延迟。（博客的例子）
当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。
如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，
同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，
接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。
slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

哨兵：redis.conf文件
这里的哨兵有两个作用
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机。

RDB和AOF
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。快照持久化是Redis默认采用的持久化方式，
与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启；开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。

redis事务
Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。redis 不支持回滚，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。如果在一个事务中的命令语法出现错误，那么所有的命令都不会执行；
如果在一个事务中出现运行错误，那么正确的命令会被执行。MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
在 multi 命令之前我们可以使用 watch 命令来”观察”一个或多个key，在事务提交之前Redis会确保被”观察”的key有没有被修改过，没有被修改过才会执行事务中的命令，如果存在key被修改过，那么整个事务中的命令都不会执行，有点类似于乐观锁的机制。
在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

String
Redis中利用SDS字符串的len属性可以直接获取到所保存的字符串的长度，直接将获取字符串长度所需的复杂度从C字符串的O(N)降低到了O(1)
使用了SDS避免了C字符串的缺陷，减少修改字符串时导致的内存重新分配次数。追加内容的长度不超过 free 属性的值， 那么就不需要对 buf 进行内存重分配，如果超过，则申请一倍内存。缩短时SDS并不会立即释放多余出来的内存空间，而是将这部分内存空间记录再其free属性中，当SDS字符串进行扩展时，这部分未使用的内存空间就能直接用，而不需要进行内存重分配，这就是SDS的惰性空间释放

list
redis3.2之前，List类型的value对象内部以linkedlist或者ziplist来实现, 当list的元素个数和单个元素的长度比较小 的时候，Redis会采用ziplist（压缩列表）来实现来减少内存占用。否则就会采用linkedlist（双向链表）结构。redis3.2之后，采用的一种叫quicklist的数据结构来存储list，列表的底层都由quicklist实现，quickList 是 zipList 和 linkedList 的混合体，它将 linkedList 按段切分，每一段使用 zipList 来紧凑存储，多个 zipList 之间使用双向指针串接起来。
Hash对象只有同时满足下面两个条件时，才会使用ziplist（压缩列表）：1.哈希中元素数量小于512个；2.哈希中所有键值对的键和值字符串长度都小于64字节。

set：
Set在的底层数据结构以intset或者hashtable来存储。当set中只包含整数型的元素时，采用intset来存储，否则， 采用hashtable存储，但是对于set来说，该hashtable的value值用于为NULL。通过key来存储元素

hash:
在redis中，hash这种结构有两种表示：zipmap和dict
为什么每个字典中包含两个hashtable？
首先Redis在正常读写时会用到一个hashtable；另一个hashtable的作用实际上是作为哈希表进行rehash时的一个临时载体。

扩容：
初始默认hash长度为4，当元素个数与hash表长度一致时，就发生扩容
-为字典的备用哈希表ht[1]分配空间（初始化）：
-ht[1]的大小为第一个>= 已使用节点数 * 2的2^n(2的n次方)。
-在字典中维持一个索引计数器变量rehashidx，并将其值设置为0，表示rehash工作正式开始（为-1时表示没有进行rehash）；
-rehash进行期间，每次对字典进行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将ht[0]哈希表在rehashidx索引上的所有键值对（这个桶中的链表）rehash到ht[1]，当一次rehash工作完成之后，程序将rehashidx属性的值+1。同时Redis会设置一个定时任务，在1ms的时间内，进行rehash处理，每次仅仅处理少量的转移任务。
-随着字典操作的不断执行，最终在某个时间点上，ht[0]的所有键值对都会被rehash到ht[1]上，这时程序将rehashidx属性的值设置为-1，表示rehash操作已经完成。

在rehash期间，字典的删除、查找、更新、增加等操作会在两个哈希表中进行。比如：
要在字典中查找某一个键，程序会现在ht[0]里面进行查找，如果没找到，就会继续到ht[1]里面进行查找。
如果是添加操作，则新添加的键值对会一律被保存到ht[1]中，而ht[0]不再进行任何添加操作：这一措施保证ht[0]中的键值对数量只减不增，并且随着操作的执行，最终变成空表。

缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
可以在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。
这里我想提的一点就是，我们在开发程序的时候都要有一颗“不信任”的心，就是不要相信任何调用方，比如你提供了API接口出去，你有这几个参数，那我觉得作为被调用方，任何可能的参数情况都应该被考虑到，做校验，因为你不相信调用你的人，你不知道他会传什么参数给你。
采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力
缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。
设置热点数据永远不过期。
缓存雪崩如果所有首页的Key失效时间都是12小时，中午12点刷新的，我零点有个秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库，数据库必然扛不住，它会报一下警，真实情况可能DBA都没反应过来就直接挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。这就是我理解的缓存雪崩。
处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效，

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？
使用keys指令可以扫出指定模式的key列表。
对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

redis优化：
1、合适时候，使用list代替set。如果你不需要使用set特性，List在使用更少内存的情况下可以提供比set更快的速度。
2、Sorted sets是最昂贵的数据结构，不管是内存消耗还是基本操作的复杂性。如果你只是需要一个查询记录的途径，并不在意排序这样的属性，那么轻建议使用哈希表。
3、尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面

分布式锁：
1、基于数据库实现分布式锁：（唯一约束可以确保一列或者几列不出现重复值）；
上面这种简单的实现有以下几个问题：
①这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
②这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
③这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
④这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
针对上面的问题,我们可以对症下药:
①数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
②没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
③非阻塞的？搞一个while循环，直到insert成功再返回成功。
④非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

2、基于缓存（Redis等）实现分布式锁；
最简单的方法是使用 setnx 命令。key 是锁的唯一标识，按业务来决定命名。比如想要给一种商品的秒杀活动加锁，可以给 key 命名为 “lock_sale_商品ID” 。
当一个线程执行 setnx 返回 1，说明 key 原本不存在，该线程成功得到了锁；当一个线程执行 setnx 返回 0，说明 key 已经存在，该线程抢锁失败。
解锁
有加锁就得有解锁。当得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。释放锁的最简单方式是执行 del 指令
释放锁之后，其他线程就可以继续执行 setnx 命令来获得锁。

setnx 指令本身是不支持传入超时时间的，set 指令增加了可选参数，
问题：假如某线程成功得到了锁，并且设置的超时时间是30秒。如果某些原因导致线程A执行的很慢很慢，过了30秒都没执行完，这时候锁过期自动释放，线程B得到了锁。随后，线程A执行完了任务，线程A接着执行del指令来释放锁。但这时候线程B还没执行完，线程A实际上删除的是线程B加的锁。
解决：我们可以让获得锁的线程开启一个守护线程，用来给快要过期的锁“续航”。当过去了 29 秒，线程 A 还没执行完，这时候守护线程会执行 expire 指令，为这把锁“续命”20 秒。守护线程从第 29 秒开始执行，每 20 秒执行一次。当线程 A 执行完任务，会显式关掉守护线程。另一种情况，如果节点 1 忽然断电，由于线程 A 和守护线程在同一个进程，守护线程也会停下。这把锁到了超时的时候，没人给它续命，也就自动释放了。
在这种场景（主从结构）中存在明显的竞态:客户端A从master获取到锁，在master将锁同步到slave之前，master宕掉了。 slave节点被晋级为master节点，客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。安全失效！

3、基于Zookeeper实现分布式锁；
四种节点：持久的、临时的、持久有序的、临时有序的
首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。
之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。
Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。
于是，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。
这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的
释放锁
释放锁分为两种情况：
1.任务完成，客户端显示释放
当任务完成时，Client1会显示调用删除节点Lock1的指令。
2.任务执行过程中，客户端崩溃
获得锁的Client1在任务执行过程中，如果Duang的一声崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。
同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Client3就会接到通知。
最终，Client3成功得到了锁。

Mybatis

一个半 ORM（ 对象关系映射）框架，它内部封装了 JDBC，开发时只需要关注 SQL 语句本身， 不需要花费精力去处理加载驱动、创建连接、创建statement 等繁杂的过程。

SqlSessionFactoryBuilder
这个类可以被实例化、使用和丢弃，一旦创建了 SqlSessionFactory，就不再需要它了。 因此 SqlSessionFactoryBuilder 实例的最佳作用域是方法作用域（也就是局部方法变量）。 你可以重用 SqlSessionFactoryBuilder 来创建多个 SqlSessionFactory 实例，但最好还是不要一直保留着它，以保证所有的 XML 解析资源可以被释放给更重要的事情。
SqlSessionFactory
SqlSessionFactory 一旦被创建就应该在应用的运行期间一直存在，没有任何理由丢弃它或重新创建另一个实例。 使用 SqlSessionFactory 的最佳实践是在应用运行期间不要重复创建多次，多次重建 SqlSessionFactory 被视为一种代码“坏习惯”。因此 SqlSessionFactory 的最佳作用域是应用作用域。 有很多方法可以做到，最简单的就是使用单例模式或者静态单例模式。
SqlSession
每个线程都应该有它自己的 SqlSession 实例。SqlSession 的实例不是线程安全的，因此是不能被共享的，所以它的最佳的作用域是请求或方法作用域。 绝对不能将 SqlSession 实例的引用放在一个类的静态域，甚至一个类的实例变量也不行。 也绝不能将 SqlSession 实例的引用放在任何类型的托管作用域中，比如 Servlet 框架中的 HttpSession。 如果你现在正在使用一种 Web 框架，考虑将 SqlSession 放在一个和 HTTP 请求相似的作用域中。 换句话说，每次收到 HTTP 请求，就可以打开一个 SqlSession，返回一个响应后，就关闭它。 这个关闭操作很重要，为了确保每次都能执行关闭操作，你应该把这个关闭操作放到 finally 块中。 下面的示例就是一个确保 SqlSession 关闭的标准模式：
try (SqlSession session = sqlSessionFactory.openSession()) {
// 你的应用逻辑代码
}
映射器实例
映射器是一些绑定映射语句的接口。映射器接口的实例是从 SqlSession 中获得的。虽然从技术层面上来讲，任何映射器实例的最大作用域与请求它们的 SqlSession 相同。但方法作用域才是映射器实例的最合适的作用域。 也就是说，映射器实例应该在调用它们的方法中被获取，使用完毕之后即可丢弃。 映射器实例并不需要被显式地关闭。尽管在整个请求作用域保留映射器实例不会有什么问题，但是你很快会发现，在这个作用域上管理太多像 SqlSession 的资源会让你忙不过来。 因此，最好将映射器放在方法作用域内。

缓存
映射语句文件中的所有 select 语句的结果将会被缓存。
映射语句文件中的所有 insert、update 和 delete 语句会刷新缓存。
缓存会使用最近最少使用算法（LRU, Least Recently Used）算法来清除不需要的缓存。
缓存会保存列表或对象（无论查询方法返回哪种）的 1024 个引用。size（引用数目）属性可以被设置为任意正整数，要注意欲缓存对象的大小和运行环境中可用的内存资源。默认值是 1024。
缓存会被视为读/写缓存，这意味着获取到的对象并不是共享的，可以安全地被调用者修改，而不干扰其他调用者或线程所做的潜在修改。
flushInterval（刷新间隔）属性可以被设置为任意的正整数，设置的值应该是一个以毫秒为单位的合理时间量。 默认情况是不设置，也就是没有刷新间隔，缓存仅仅会在调用语句时刷新。
readOnly（只读）属性可以被设置为 true 或 false。只读的缓存会给所有调用者返回缓存对象的相同实例。 因此这些对象不能被修改。这就提供了可观的性能提升。而可读写的缓存会（通过序列化）返回缓存对象的拷贝。 速度上会慢一些，但是更安全，因此默认值是 false。

一级缓存
SqlSession级别缓存，作用域在一次会话之间有效，默认开启， HashMap本地缓存
运行原理：第一次执行select操作完毕后，会将查询到的结果缓存到map中。第二次执行select操作时，如果传入的参数一样，就不去查询数据库而是直接返回，这样提高了效率。
二级缓存
SqlSessionFactory级别缓存，作用域在同一个namespace有效，默认关闭，HashMap存储
如何配置 在mybatis配置文件中加入"cacheEnabled" value=“true”
运行原理：当一个sqlsession进行select操作完毕时，将查询到的结果缓存到map中。当另一个sqlsession进行select操作时，先查询是否有一级缓存，如果没有再去查找二级缓存，找到了就换回，这样减少了服务器压力，提高性能。
二级缓存是事务性的。这意味着，当 SqlSession 完成并提交时，或是完成并回滚，但没有执行 flushCache=true 的 insert/delete/update 语句时，缓存会获得更新。

mybatis分页

1. 逻辑分页——RowBounds
   通过RowBounds类可以实现Mybatis逻辑分页，原理是首先将所有结果查询出来，然后通过计算offset和limit，只返回部分结果，操作在内存中进行，所以也叫内存分页。弊端很明显，当数据量比较大的时候，肯定是不行的，所以一般不会去使用RowBounds进行分页查询。Mybatis Generator原生支持RowBounds查询，生成的Mapper接口中存在一个方法selectByExampleWithRowbounds就是通过RowBounds进行分页查询
2. 物理分页——直接为sql添加limit
   如果可以在查询时直接在sql中指定limit，name肯定是只查询相应页的数据。所以就有一种直观的现象，比如使用mybatis，如果可以在mapper.xml中添加limit属性，那生成的sql肯定是可以直接查询到相应页的数据的。结合之前使用的Mybatis Generator，可以这样实现：首先在生成的XxxExample中加入两个属性limit和offset，同时加上set和get方法，然后在XxxMapper.xml中在通过selectByExample查询时，添加limit，
   其实手动去加工作量也不大，但是如果表比较多，添加起来还是有一定工作量的。而且加入下次表结构变更，重新通过Mybatis Generator生成的话，这些信息也要重新加入。为了避免这些麻烦，有大神写了一个Mybatis Generator插件MySQLLimitPlugin，可以在Mybatis Generator生成文件的时候自动生成上述信息，本片文章就使用MySQLLimitPlugin插件进行生成。
3. 物理分页——拦截器PageHelper
   PageHelper是一款好用的开源免费的Mybatis第三方物理分页插件，在配置了PageHelper的page number和size，调用完startPage后，它会通过PageInterceptor对其后的第一个执行sql进行拦截，比如List list = userService.findAllUser()，这里原本的sql可能是 select * from users，它会自动拼接上分页的sql语句，比如mysql环境的话，就是拼接上limit语句，随后执行，最后的结果，可以通过PageInfo和Page进行获取。

MyBatis 的 mapper 接口调用时有哪些要求？
A. Mapper 接口方法名和 mapper.xml 中定义的每个 sql 的 id 相同
B. Mapper 接口方法的输入参数类型和 mapper.xml 中定义的每个 sql 的 parameterType 的类型相同
C. Mapper 接口方法的输出参数类型和 mapper.xml 中定义的每个 sql 的 resultType 的类型相同
D. Mapper.xml 文件中的 namespace 即是 mapper 接口的类路径

1）#{}是预编译处理，{}是字符串替换。
2）Mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值；
3）Mybatis在处理{}时，就是把{}替换成变量的值。
4）使用#{}可以有效的防止SQL注入，提高系统安全性。
1、能使用 #{ } 的地方就用 #{ }
首先这是为了性能考虑的，相同的预编译 sql 可以重复利用。其次，${ } 在预编译之前已经被变量替换了，这会存在 sql 注入问题
2、表名作为变量时，必须使用 ${ }
这是因为，表名是字符串，使用 sql 占位符替换字符串时会带上单引号 ‘’，这会导致 sql 语法错误，例如：
select * from #{tableName} where name = #{name};
预编译之后的sql 变为：
select * from ? where name = ?;
假设我们传入的参数为 tableName = “user” , name = “Jack”，那么在占位符进行变量替换后，sql 语句变为：
select * from ‘user’ where name=‘Jack’;

Dao接口的工作原理是什么？Dao接口里的方法，参数不同时，方法能重载吗？
Dao接口即Mapper接口。接口的全限名，就是映射文件中的namespace的值；接口的方法名，就是映射文件中Mapper的Statement的id值；接口方法内的参数，就是传递给sql的参数。
Mapper接口是没有实现类的，当调用接口方法时，接口全限名+方法名拼接字符串作为key值，可唯一定位一个MapperStatement。在Mybatis中，每一个select、insert、update、delete标签，都会被解析为一个MapperStatement对象。
Mapper接口里的方法，是不能重载的，因为是使用 全限名+方法名 的保存和寻找策略。Mapper 接口的工作原理是JDK动态代理，Mybatis运行时会使用JDK动态代理为Mapper接口生成代理对象proxy，代理对象会拦截接口方法，转而执行MapperStatement所代表的sql，然后将sql执行结果返回。
不同的Xml映射文件，如果配置了namespace，那么id可以重复；如果没有配置namespace，那么id不能重复；

延迟加载的原理是，使用CGLIB创建目标对象的代理对象，当调用目标方法时，进入拦截器方法，比如调用a.getB().getName()，拦截器invoke()方法发现a.getB()是null值，那么就会单独发送事先保存好的查询关联B对象的sql，把B查询上来，然后调用a.setB(b)，于是a的对象b属性就有值了，接着完成a.getB().getName()方法的调用。这就是延迟加载的基本原理。

Mybatis是如何将sql执行结果封装为目标对象并返回的？都有哪些映射形式？
第一种是使用标签，逐一定义数据库列名和对象属性名之间的映射关系。
第二种是使用sql列的别名功能，将列的别名书写为对象属性名。
有了列名与属性名的映射关系后，Mybatis通过反射创建对象，同时使用反射给对象的属性逐一赋值并返回，那些找不到映射关系的属性，是无法完成赋值的。

mq

Kafka是分布式发布-订阅消息系统，Kafka是一个分布式，冗余备份的持久性的日志服务，它主要用于处理流式数据。作用：
缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。
解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。
冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。
健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。
异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

可靠性
临界值情况：
情况一：生产端投递消息失败，消费端未收到消息。
情况二：生产端投递消息了，消费端也收到了，但在返回应答过程中，突然网络中断了导致发送端未收到确认应答。
解决：在生产者端配置开启Confirm模式，每次向MQ发送的每一条消息都会被分配上唯一一个消息ID，在MQ接收到消息之后，会返回一个ack通知发送成功，相反如果没有接收到这个消息，则会回调nack接口，可以在回调方法中做重发。Confirm机制是异步操作进行的。

有序性
通过轮询所有队列的方式来确定消息被发送到哪一个队列（负载均衡策略）（分区）。订单号相同的消息会被先后发送到同一个队列中，

幂等性
可在内存中维护一个set，只要从消息队列里面获取到一个消息，先查询这个消息在不在set里面，如果在表示已消费过，直接丢弃；如果不在，则在消费后将其加入set当中。

消息中间件的组成
1 Broker：消息服务器，作为server提供消息核心服务
2 Producer：消息生产者，业务的发起方，负责生产消息传输给broker，
3 Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理
4 Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播
5 Queue：队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
6 Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

spring

Spring Boot基本上是Spring框架的扩展，它消除了设置Spring应用程序所需的XML配置
启动流程：
1.首先，对于一个web应用，其部署在web容器中，web容器提供其一个全局的上下文环境，这个上下文就是ServletContext，其为后面的spring IoC容器提供宿主环境；
2.其 次，在web.xml中会提供有contextLoaderListener。在web容器启动时，会触发容器初始化事件，此时 contextLoaderListener会监听到这个事件，其contextInitialized方法会被调用，在这个方法中，spring会初始 化一个启动上下文，这个上下文被称为根上下文，即WebApplicationContext，这是一个接口类，确切的说，其实际的实现类是 XmlWebApplicationContext。这个就是spring的IoC容器，其对应的Bean定义的配置由web.xml中的 context-param标签指定。在这个IoC容器初始化完毕后，spring以WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE为属性Key，将其存储到ServletContext中，便于获取；
3.再次，contextLoaderListener监听器初始化完毕后，开始初始化web.xml中配置的Servlet，这里是DispatcherServlet，这个servlet实际上是一个标准的前端控制器，用以转发、匹配、处理每个servlet请 求。DispatcherServlet上下文在初始化的时候会建立自己的IoC上下文，用以持有spring mvc相关的bean。在建立DispatcherServlet自己的IoC上下文时，会利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE先从ServletContext中获取之前的根上下文(即WebApplicationContext)作为自己上下文的parent上下文。有了这个 parent上下文之后，再初始化自己持有的上下文。这个DispatcherServlet初始化自己上下文的工作在其initStrategies方 法中可以看到，大概的工作就是初始化处理器映射、视图解析等。这个servlet自己持有的上下文默认实现类也是 XmlWebApplicationContext。初始化完毕后，spring以与servlet的名字相关(此处不是简单的以servlet名为 Key，而是通过一些转换，具体可自行查看源码)的属性为属性Key，也将其存到ServletContext中，以便后续使用。这样每个servlet 就持有自己的上下文，即拥有自己独立的bean空间，同时各个servlet共享相同的bean，即根上下文(第2步中初始化的上下文)定义的那些 bean。

1、AOP（面向切面）是一种编程范式，提供从另一个角度来考虑程序结构以完善面向对象编程（OOP），装饰者模式。
2、IOC（控制反转）就是依赖倒置原则的一种代码设计思路。就是把原先在代码里面需要实现的对象创建、对象之间的依赖，反转给容器来帮忙实现：工厂模式、Java反射机制。
3、依赖注入（Dependency Injection），即组件之间的依赖关系由容器在应用系统运行期来决定，也就是由容器动态地将某种依赖关系的目标对象实例注入到应用系统中的各个关联的组件之中。组件不做定位查询，只提供普通的Java方法让容器去决定依赖关系。

依赖注入方式：
构造器依赖注入：构造器依赖注入通过容器触发一个类的构造器来实现的，该类有一系列参数，每个参数代表一个对其他类的依赖。
Setter方法注入：Setter方法注入是容器通过调用无参构造器或无参static工厂 方法实例化bean之后，调用该bean的setter方法，即实现了基于setter的依赖注入。
接口注入

配置 Bean 的方式：基于XML的配置、基于注解的配置、基于Java的配置

管理事务的方式：1、编程式事务，在代码中硬编码。(不推荐使用)2、声明式事务，在配置文件中配置（推荐使用）

声明式事务：spring使用AOP来支持声明式事务，会根据事务属性，自动在方法调用之前决定是否开启一个事务，并在方法执行之后决定事务提交或回滚事务。声明式的事务的做法是在a方法外围添加注解或者直接在配置文件中定义,a方法需要事务处理,在spring中会通过配置文件在a方法前后拦截,并添加事务.声明式事务又分为两种：a、基于XML的声明式事务；b、基于注解的声明式事务
编程式事务管理：编程式事务需要你在代码中直接加入处理事 务的逻辑,可能需要在代码中显式调用beginTransaction()、commit()、rollback()等事务管理相关的方法,如在执行a方 法时候需要事务处理,你需要在a方法开始时候开启事务,处理完后。在方法结束时候,关闭事务.
编程式事务侵入性比较强，但处理粒度更细.

切面
连接点（JoinPoint）：需要在程序中插入横切关注点的点，连接点可能是在类初始化、方法调用、字段调用或处理异常等等。Spring中只支持方法执行连接点。
切入点（Pointcut）：一组相关连接点的集合。
通知（Advice）：在连接点上执行的行为，增强提供了在AOP中需要在切入点所选择的连接点处进行扩展现有行为的手段。包括前置增强（before advice）、后置增强 (after advice)、环绕增强 （around advice）、异常通知、返回通知。
切面（Aspect）：通知和切入点的结合。
织入（Weaving）：织入是一个过程，是将切面应用到目标对象从而创建出AOP代理对象的过程。
代理（Proxy）：通过代理方式来对目标对象应用切面。AOP代理可以用JDK动态代理或CGLIB代理实现。
目标对象（Target）：需要被织入关注点的对象。即被代理的对象。

JDK和CGLIB：
JDK动态代理只提供接口的代理。核心InvocationHandler接口和Proxy类，InvocationHandler 通过invoke()方法反射来调用目标类中的代码，动态地将横切逻辑和业务编织在一起；接着，Proxy利用 InvocationHandler动态创建一个符合某一接口的的实例, 生成目标类的代理对象。
如果代理类没有实现 InvocationHandler 接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB（Code Generation Library），可以代理类和接口。CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。

静态代理与动态代理（反射）区别在于生成AOP代理对象的时机不同。

ApplicationContext和BeanFactory
BeanFactory：是Spring里面最底层的接口，包含了各种Bean的定义，读取bean配置文档，管理bean的加载、实例化，控制bean的生命周期，维护bean之间的依赖关系。IoC 在 Spring 里，只需要低级容器就可以实现，2 个步骤：加载配置文件，解析成 BeanDefinition 放在 Map 里；调用 getBean 的时候，从 BeanDefinition 所属的 Map 里，拿出 Class 对象进行实例化，同时，如果有依赖关系，将递归调用 getBean 方法 —— 完成依赖注入。
ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具有的功能外，提供在监听器中注册bean的事件。

加载方式
BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。
ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。 ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。
相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。

bean的作用域：
singleton : bean在每个Spring ioc 容器中只有一个实例。
prototype：一个bean的定义可以有多个实例。
request：每次http请求都会创建一个bean，该作用域仅在基于web的Spring ApplicationContext情形下有效。
session：在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。
global-session：在一个全局的HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。

在一般情况下，只有无状态的Bean才可以在多线程环境下共享，在Spring中，绝大部分Bean都可以声明为singleton作用域，因为Spring对一些Bean中非线程安全状态采用ThreadLocal进行处理，解决线程安全问题。

注解
@Component：这将 java 类标记为 bean。它是任何 Spring 管理组件的通用构造型。spring 的组件扫描机制现在可以将其拾取并将其拉入应用程序环境中。
@Controller：这将一个类标记为 Spring Web MVC 控制器。标有它的 Bean 会自动导入到 IoC 容器中。
@Service：此注解是组件注解的特化。它不会对 @Component 注解提供任何其他行为。您可以在服务层类中使用 @Service 而不是 @Component，因为它以更好的方式指定了意图。
@Repository：这个注解是具有类似用途和功能的 @Component 注解的特化。它为 DAO 提供了额外的好处。它将 DAO 导入 IoC 容器，并使未经检查的异常有资格转换为 Spring DataAccessException

@Autowired按byType自动注入，而@Resource默认按 byName自动注入，默认情况下必须要求依赖对象必须存在，如果要允许null值，可以设置它的required属性为false。
@Resource有两个属性分是name和type，Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。

bean生命周期

数据库

sql删除重复语句
1、select distinct name,class from user
2、delete from people
where peopleName in (select peopleName from people group by peopleName having count(peopleName) > 1)
and peopleId not in (select min(peopleId) from people group by peopleName having count(peopleName)>1)
sql面试题

视图
1、作为一个抽象装置，程序本身不关心基表结构，只需要按照视图定义来获取数据或者更新数据，因此视图在一定程序上也起到一个安全层的作用；
2、视图能简化用户操作；
3、视图使用户以多种角度看待同一数据；
4、视图对重构数据库提供了一定程度的逻辑独立性；
5、适当的利用视图可以更清晰地表达查询。

主从复制

主库db的更新事件(update、insert、delete)被写到binlog
主库创建一个binlog dump thread，把binlog的内容发送到从库
从库启动并发起连接，连接到主库
从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
从库启动之后，创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

canal模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议
mysql master收到dump请求，开始推送binary log为slave
canal解析binary log对象（原始为byte流）

mysql的binlog是多文件存储，定位一个LogEvent需要通过binlog filename + binlog position，进行定位；
mysql的binlog数据格式，按照生成的方式，主要分为：statement-based、row-based、mixed。目前canal支持所有模式的增量订阅(但配合同步时，因为statement只有sql，没有数据，无法获取原始的变更日志，所以一般建议为ROW模式)

get/ack/rollback协议介绍：
1、Message getWithoutAck(int batchSize)，允许指定batchSize，一次可以获取多条，每次返回的对象为Message，包含的内容为：
a. batch id 唯一标识
b. entries 具体的数据对象，对应的数据对象格式：

Entry
    Header
        logfileName [binlog文件名]
        logfileOffset [binlog position]
        executeTime [binlog里记录变更发生的时间戳]
        schemaName [数据库实例]
        tableName [表名]
        eventType [insert/update/delete类型]
    entryType   [事务头BEGIN/事务尾END/数据ROWDATA]
    storeValue  [byte数据,可展开，对应的类型为RowChange]

RowChange
isDdl       [是否是ddl变更操作，比如create table/drop table]
sql     [具体的ddl sql]
rowDatas    [具体insert/update/delete的变更数据，可为多条，1个binlog event事件可对应多条变更，比如批处理]
beforeColumns [Column类型的数组]
afterColumns [Column类型的数组]

Column
index       [column序号]
sqlType     [jdbc type]
name        [column name]
isKey       [是否为主键]
updated     [是否发生过变更]
isNull      [值是否为null]
value       [具体的内容，注意为文本]

void rollback(long batchId)，顾命思议，回滚上次的get请求，重新获取数据。基于get获取的batchId进行提交，避免误操作
void ack(long batchId)，顾命思议，确认已经消费成功，通知server删除数据。基于get获取的batchId进行提交，避免误操作

canal的get/ack/rollback协议和常规的jms协议有所不同，允许get/ack异步处理，比如可以连续调用get多次，后续异步按顺序提交ack/rollback，mark标记

读写异常
丢失修改：两个事务T1，T2读入同一数据并修改，T2提交的结果被T1破坏了，导致T1的修改丢失。
读脏数据：事务T1修改某个数据并写回磁盘，事务T2读取同一数据，但T1由于某种原因撤销了，这时T1修改过的数据恢复原来的值，T2读取的数据就与数据库中的数据不一致。
不可重复读：事务T1读取数据后，事务T2执行更新操作，使T1无法再次读取结果。
幻读：事务在操作过程中进行两次查询，第二次查询结果包含了第一次查询中未出现的数据（这里并不要求两次查询SQL语句相同）这是因为在两次查询过程中有另外一个事务插入数据造成的。

任何一条DML语句执行，标志事务的开启
开启事务 start transaction；提交事务/回滚事务. commit / rollback

事务的隔离级别
1、未提交读(READ UNCOMMITTED)会导致“脏读”、“幻读”和“不可重复读取”。
不加锁
2、提交读（Read Committed）“幻读”和“不可重复读取”。
这是互联网最常用的隔离级别，在RC下：
(1)普通读是快照读；
(2)加锁的select, update, delete等语句，除了在外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会封锁区间，其他时刻都只使用记录锁；
此时，其他事务的插入依然可以执行，就可能导致，读取到幻影记录。。
3、可重复读（Repeatable Read）幻读
这是InnoDB默认的隔离级别，在RR下：
(1)普通的select使用快照读(snapshot read)，这是一种不加锁的一致性读(Consistent Nonlocking Read)，底层使用MVCC来实现。
(2)加锁的select(select … in share mode / select … for update), update, delete等语句，它们的锁，依赖于它们是否在唯一索引(unique index)上使用了唯一的查询条件(unique search condition)，或者范围查询条件(range-type search condition)：
唯一索引上使用唯一的查询条件，会使用记录锁(record lock)，不会使用间隙锁(gap lock)与临键锁(next-key lock)
范围查询条件，会使用间隙锁与临键锁
4、可序列化(Serializable) 读写数据都会锁住整张表
最高的隔离级别，它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

mvcc是一种用来解决读-写冲突的无锁并发控制
Innodb的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了这个行的创建时间，另一个保存的是行的删除时间。这里存储的并不是实际的时间值，而是系统版本号，每开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID。
SELECT：
InnoDB会根据以下两个条件检查每行记录，查询结果必须同时满足这两个条件。
1、InnoDB只会查找版本早于当前事务版本的数据行（即行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在，要么是事务自身插入或修改过。
2、行的删除版本要么未定义，要么大于当前事务版本号，这可以确保事务读取到的行，在事务开始之前未被删除。
DELETE：
InnoDB会为删除的每一行保存当前系统的版本号（事务的ID）作为删除标识。
为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

MyISAM 在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作 (UPDATE、DELETE、INSERT 等)前，会自动给涉及的表加写锁
一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL让写进程先获得锁。不仅如此，即使读进程先请求先到锁等待队列，写请求后到，写锁也会插到读请求之前！这是因为MySQL认为写请求一般比读请求重要。这也正是MyISAM表不太适合于有大量更新操作和查询操作应用的原因，因为，大量的更新操作会造成查询操作很难获得读锁，从而可能永远阻塞。我们可以通过一些设置来调节MyISAM的调度行为：
1、通过指定启动参数low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利。
2、通过执行命令SET LOW_PRIORITY_UPDATES=1，使该连接发出的更新请求优先级降低。
3、通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。

每个MyISAM在磁盘上存储成三个文件。
（1）frm文件：存储表的定义数据
（2）MYD文件：存放表具体记录的数据
（3）MYI文件：存储索引
frm和MYI可以存放在不同的目录下。MYI文件用来存储索引，但仅保存记录所在页的指针，索引的结构是B+树结构。
支持数据的类型也有三种：
（1）静态固定长度表
这种方式的优点在于存储速度非常快，容易发生缓存，而且表发生损坏后也容易修复。缺点是占空间。这也是默认的存储格式。
（2）动态可变长表
优点是节省空间，但是一旦出错恢复起来比较麻烦。
（3）压缩表
上面说到支持数据压缩，说明肯定也支持这个格式。在数据文件发生错误时候，可以使用check table工具来检查，而且还可以使用repair table工具来恢复。
有一个重要的特点那就是不支持事务，但是这也意味着他的存储速度更快，如果你的读写操作允许有错误数据的话，只是追求速度，可以选择这个存储引擎。

InnoDB是默认的数据库存储引擎，聚簇索引，支持外键，innodb page默认16kb，
对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；
他的主要特点有：
（1）可以通过自动增长列，方法是auto_increment。
（2）支持事务。默认的事务隔离级别为可重复度，通过MVCC（并发版本控制）来实现的。
（3）使用的锁粒度为行级锁，可以支持更高的并发；
（4）支持外键约束；外键约束其实降低了表的查询速度，但是增加了表之间的耦合度。
（5）配合一些热备工具可以支持在线热备份；
（6）在InnoDB中存在着缓冲管理，通过缓冲池，将索引和数据全部缓存起来，加快查询的速度；
（7）对于InnoDB类型的表，其数据的物理组织形式是聚簇表。所有的数据按照主键来组织。数据和索引放在一块，都位于B+数的叶子节点上；

对于InnoDB来说，最大的特点在于支持事务。但是这是以损失效率来换取的。

二级索引：叶子节点中存储主键值，每次查找数据时，根据索引找到叶子节点中的主键值，根据主键值再到聚簇索引中得到完整的一行记录。
InnoDB在移动行时，无需维护二级索引，因为叶子节点中存储的是主键值，而不是指针。而唯一索引、普通索引、前缀索引等都是二级索引。

索引类型(普通索引，唯一索引：可以为空，主键索引)、组合索引、全文索引。
事务的特性：原子性，一致性，隔离性，持久性

为什么自增列ID设置为主键?
如果定义了主键,那么InnoDB会选择主键作为聚集索引,如果没有显示定义主键,那么InnoDB会选择第一个不含null的唯一索引作为主键索引,如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的隐含的聚集索引(不可引用)。
InnoDB引擎是B+树的结构,数据记录是被存储在主索引的叶子结点上,所以这就要求同一个叶子结点内的各项数据记录按照主键的顺序存放,因此每当有一个新的记录被插入时,InnoDB会根据其主键的大小为其寻找合适的节点和位置插入,如果页面已经达到了装填因子(默认15/16),则开辟新的一页(节点)
如果表使用自增主键,那么每次插入新纪录,记录就会顺序添加到当前索引节点的后续位置,当一页写满,就会自动开辟新的一页
如果使用非自增主键（比如用户ID等），那么每次插入主键的值都差不多近似于随机，每次新纪录都要被插到现有索引页得中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过优化表操作来重建表并优化填充页面
当使用自增列作为主键时，存取效率是最高的

自增id是增长的 不一定连续。造成自增id不连续的情况可能有：
1.唯一键冲突
2.事务回滚
3.insert … select语句批量申请自增id

适合的场景
MyISAM：频繁执行全表count语句（MyISAM用一个变量保存了整个表的函数）；对数据进行增删改的频率不高、查询非常频繁；没有事务
InnoDB：数据增删改都相当频繁；可靠性要求比较高，需要支持事务

1. MySQL缓存机制说明
   MySQL缓存机制即缓存sql 文本及缓存结果，用KV形式保存再服务器内存中，如果运行相同的sql，服务器直接从缓存中去获取结果，不需要再去解析、优化、执行sql
2. MySQL缓存失效
   在表的结构或数据发生改变时，查询缓存中的数据不再有效，查询缓存值的相关条目将被清空
   INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE会导致缓存数据失效
3. 使用场景
   对于频繁更新的表，查询缓存不合适
   对于一些不变的数据且有大量相同sql查询的表，查询缓存可以大大提高查询的性能
4. 命中条件
   缓存的数据结构是hash表
   以SQL、数据库名和客户端协议等作为KEY
   在判断命中前，MySQL不会解析SQL，而是使用SQL去查询缓存，SQL上的任何字符的不同，如空格、注释等都会导致缓存不命中
   如果查询有不确定的数据，如like now()、current_date()，那么查询完成后结果都不会被缓存

Ｂ树和Ｂ＋树的出现是因为另外一个问题，那就是磁盘ＩＯ；众所周知，ＩＯ操作的效率很低，那么，当在大量数据存储中，查询时我们不能一下子将所有数据加载到内存中，只能逐一加载磁盘页，每个磁盘页对应树的节点。造成大量磁盘ＩＯ操作（最坏情况下为树的高度）。平衡二叉树由于树深度过大而造成磁盘IO读写过于频繁，进而导致效率低下。
　　所以，我们为了减少磁盘ＩＯ的次数，就你必须降低树的深度，将“瘦高”的树变得“矮胖”。一个基本的想法就是：
　　（1）每个节点存储多个元素
　　（2）摒弃二叉树结构，采用多叉树
B+树和B树有什么不同
1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
4.在范围查询方面：B树的范围查找需要不断依赖中序遍历。首先二分查找到范围下限，在不断通过中序遍历，知道查找到范围的上限即可。整个过程比较耗时。 而B+树的范围查找则简单了许多。首先通过二分查找，找到范围下限，然后同过叶子结点的链表顺序遍历，直至找到上限即可，整个过程简单许多，效率也比较高。

数据库优化：
1、选取最适用的字段属性
MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。
例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。
另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。
对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。
存储IP地址时最好使用无符号整数，而不是字符串，这样可以节省存储空间，Inet_ATON()将带点儿的IP转为数字，而Inet_NTOA可将数字转为IP。
2、使用索引：一般说来，索引应建立在那些将用于JOIN,WHERE判断和ORDERBY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。
3、优化的查询语句：
不要在查询中使用 !=、not in、not exists
不要在where条件的等号左侧中使用函数
MySQL支持前缀索引，但是不支持后缀索引LIKE '%A’优化为： LIKE ‘A%’
设置联合索引时，索引的建立顺序要和where或者order by条件中的字段顺序相同，如建立name、status（分别为key1、key2）的联合索引，此时以name字段为第一查询顺序的索引有效
where条件中有or，需将or中的每个字段都加上索引
状态值少的字段不宜使用索引
数据类型不匹配
limit优化：where id>= (select id from mytbl order by id limit 100000,1)limit 10
4、开启慢查询日志：slow_query_log ：是否开启慢查询日志，1表示开启，0表示关闭。
5、如果要定量分析查询语句涉及到了多少行，可以使用explain。explain语句是非常重要的分析工具。提测之前使用explain分析一下SQL语句是一种美德。
6、使用连接（JOIN）来代替子查询(Sub-Queries)
7、使用联合(UNION)来代替手动创建的临时表
8、事务

乐观锁：顾名思义，对加锁持有一种乐观的态度，即先进行业务操作，不到最后一步不进行加锁，"乐观"的认为加锁一定会成功的，在最后一步更新数据的时候再进行加锁。

悲观锁：正如其名字一样，悲观锁对数据加锁持有一种悲观的态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

实现方式：
乐观锁：
version方式：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
CAS：即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

悲观锁：是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了(原理：共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程)，如行锁、读锁和写锁等，都是在操作之前加锁，在Java中，synchronized的思想也是悲观锁。

使用场景
乐观锁：比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。乐观锁不能解决脏读的问题。

悲观锁：比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

es
开源数据库产品近10年来百花齐放，10年前还是关系型数据库的天下， 因为他们有天然优势，一通用，二保证了数据一致性，当然缺点也不少。

随着互联网的高速发展，业务也随之变得复杂，数据量呈指数级增长，所以近年来诞生了很多非关系型数据库，比如k-v类型的redis，文档数据库 mongodb， elasticsearch，等等。

最近我遇到一个问题就是某个业务数据量已经到了千万级别， 还在持续增长，因为数据库用的是 MySQL，在可以遇见的一段时间后，这个表将面临数据查询慢的性能瓶颈。

千万级数据量当然不是简单列加个索引就能解决问题的，毕竟重新建索引就是个非常缓慢的过程。

所以不得不做分表分库处理，虽然MySQL已经有很多成熟的分表分库的中间件，但好像针对python的并不多。 分表分库麻烦，是垂直分还是水平分，根据什么字段来分，都是要考虑的问题，要改动的业务逻辑代码也不少

这个时候MySQL在扩展性方面就并没有那些NoSQL灵活了，天然就是为分布式而生的mongodb，elasticsearch 就不会遇到这样的问题，真遇到了瓶颈只要怼机器就行。

也是主从复制

Mongodb是非关系型数据库(nosql ),属于文档型数据库。文档是mongoDB中数据的基本单元，类似关系数据库的行，它是一个面向集合的，模式自由的文档型数据库。
存储方式：虚拟内存+持久化。
查询语句：是独特的Mongodb的查询方式。
适合场景：事件的记录，内容管理或者博客平台等等。
架构特点：可以通过副本集，以及分片来实现高可用。
数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
优点：
快速！在适量级的内存的Mongodb的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。高扩展性，存储的数据格式是json格式！
缺点：
不支持事务，而且开发文档不是很完全，完善。

一个database中所有的collections以及索引信息会分散存储在多个数据文件中，即mongodb并没有像SQL数据库那样，每个表的数据、索引分别存储；数据分块的单位为extent（范围，区域），即一个data file中有多个extents组成，extent中可以保存collection数据或者indexes数据，一个extent只能保存同一个collection数据，不同的collections数据分布在不同的extents中，indexes数据也保存在各自的extents中；最终，一个collection有一个或者多个extents构成，最小size为8K，最大可以为2G，依次增大；它们分散在多个data files中。对于一个data file而言，可能包含多个collection的数据，即有多个不同collections的extents、index extents混合构成。每个extent包含多条documents（或者index entries），每个extent的大小可能不相等，但一个extent不会跨越2个data files。
每个collection只保存了第一个extent的位置信息，并不保存所有的extents列表，但每个extent都维护者一个链表关系，即每个extent都在其header信息中记录了此extent的上一个、下一个extent的位置信息，这样当对此collection进行scan操作时（比如全表扫描），可以提供很大的便利性。
对于write操作而言，首先写入journal日志，然后将数据在内存中修改（mmap），此后后台线程间歇性的将内存中变更的数据flush到底层的data files中，时间间隔为60秒（参见配置项“syncPeriodSecs”）；write操作在journal文件中是有序的，为了提升性能，write将会首先写入journal日志的内存buffer中，当buffer数据达到100M或者每隔100毫秒，buffer中的数据将会flush到磁盘中的journal文件中；如果mongodb异常退出，将可能导致最多100M数据或者最近100ms内的数据丢失，flush磁盘的时间间隔有配置项“commitIntervalMs”决定，默认为100毫秒。

数据分层
1）ODS层（原始数据层）
原始数据层，存放原始的数据，直接加载原始日志、数据，数据保持原貌不作处理。
2）DWD层（明细数据层）
结构和粒度与原始数据表保持一致，对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）
3）DWS层（服务数据层）
以DWD为基础，进行轻度汇总。一般聚集到以用户当日，设备当日，商家当日，商品当日等等的粒度
4）ADS层（数据应用层）
ADS层，为各种统计表提供数据，也有的地方把这层叫做APP层、DM层等等。

大数据

Hadoop是一个分布式系统基础架构。解决了大数据（大到一台计算机无法进行存储，一台计算机无法在要求的时间内进行处理）的可靠存储(HDFS)和处理(MapReduce)。
Hive是建立在Hadoop之上的，使用Hadoop作为底层存储的批处理系统。（可以理解为MapReduce的一层壳）Hive是为了减少MapReduce jobs的编写工作。
HBase是一种Key/Value系统，它运行在HDFS之上。Hbase是为了解决Hadoop的实时性需求。
Spark和Storm都是通用的并行计算框架。解决Hadoop只适用于离线数据处理，而不能提供实时数据处理能力的问题。
HIve清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase
数据应用从HBase查询数据；

操作系统

阻塞IO 非阻塞IO 多路IO 信号驱动 异步IO

①阻塞：为了完成一个功能，发起调用，若当前不具备完成条件则一直等待。
②非阻塞：为了完成一个功能，发起调用，若当前不具备完成条件则直接报错返回。
③阻塞与非阻塞区别：发起调用在不具备完成调用的情况下是否等待。
④同步：处理流程，顺序处理，一个完成了之后再完成另一个，所有功能都有进程自己进行完成。
⑤异步：处理流程中，顺序不定，因为功能都由操作系统完成。
⑥异步阻塞：功能由别人完成，调用中等待别人完成。
⑦异步非阻塞：功能有别人完成，调用是立即返回的。

阻塞IO
第一阶段:当用户进程调用了recvfrom这个系统调用，
kernel就开始了IO的第一个阶段：准备数据。
对于network io来说，
很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），
这个时候kernel就要等待足够的数据到来。
而在用户进程这边，整个进程会被阻塞。

第二阶段:当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，
然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段都被block了。

非阻塞IO模型
第一阶段:当用户进程发出read操作时，如果kernel中的数据还没有准备好，
那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，
它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。
用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。
第二阶段:一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，
那么它马上就将数据拷贝到了用户内存，然后返回。
所以，用户进程其实是需要不断的主动询问kernel数据好了没有。

IO复用模型
第一阶段:用户进程调用了select，整个进程会被block，
而同时，kernel会“监视”所有select负责的socket，
当任何一个socket中的数据准备好了，select就会返回。
第二阶段:这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。
整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

信号驱动IO模型
第一阶段:当需要等待数据的时候，首先用户态会向内核发送一个信号，
告诉内核我要什么数据，等到这个数据来的时候给它发信号
然后用户态就不管了，做别的事情去了.

第二阶段:当内核态中的数据准备好之后，内核立马发给用户态一个信号，
说”数据准备好了，快来查收“，用户态进程收到之后，
立马调用recvfrom，等待数据从内核空间复制到用户空间，
待完成之后recvfrom返回成功指示，用户态进程才处理别的事情。
通过上面的图，可以看出信号驱动式I/O模型有种异步操作的赶脚，
但是在将数据从内核复制到用户空间这段时间内用户态进程是阻塞的

异步IO模型
第一阶段 首先用户态进程告诉内核态需要什么数据，
然后用户态进程就不管了，做别的事情.
第二阶段:内核等待用户态需要的数据准备好，然后将数据复制到用户空间，
此时才告诉用户态进程，”数据都已经准备好，请查收“，
然后用户态进程直接处理用户空间的数据。
在复制数据到用户空间这个时间段内，用户态进程也是不阻塞的

很少有Linux系统支持这种模型 在Windows下的IOCP就是该模型

底层
select函数是一个阻塞函数
使用起来很清晰，首先要调用epoll_create建立一个epoll对象。参数size是内核保证能够正确处理的最大句柄数，多于这个最大数时内核可不保证效果。
epoll_ctl可以操作上面建立的epoll，例如，将刚建立的socket加入到epoll中让其监控，或者把 epoll正在监控的某个socket句柄移出epoll，不再监控它等等。
epoll_wait在调用时，在给定的timeout时间内，当在监控的所有句柄中有事件发生时，就返回用户态的进程。



传统 BIO
采用 BIO 通信模型 的服务端，通常由一个独立的 Acceptor 线程负责监听客户端的连接。我们一般通过在 while(true) 循环中服务端会调用 accept() 方法等待接收客户端的连接的方式监听请求，请求一旦接收到一个连接请求，就可以建立通信套接字在这个通信套接字上进行读写操作，此时不能再接收其他客户端连接请求，只能等待同当前连接的客户端的操作执行完成， 不过可以通过多线程来支持多个客户端的连接。

如果要让 BIO 通信模型 能够同时处理多个客户端请求，就必须使用多线程（主要原因是 socket.accept()、 socket.read()、 socket.write() 涉及的三个主要函数都是同步阻塞的），也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的 一请求一应答通信模型 。我们可以设想一下如果这个连接不做任何事情的话就会造成不必要的线程开销，不过可以通过 线程池机制 改善，线程池还可以让线程的创建和回收成本相对较低。使用FixedThreadPool 可以有效的控制了线程的最大数量，保证了系统有限的资源的控制，实现了N(客户端请求数量):M(处理客户端请求的线程数量)的伪异步I/O模型（N 可以远远大于 M）。

我们再设想一下当客户端并发访问量增加后这种模型会出现什么问题？
在 Java 虚拟机中，线程是宝贵的资源，线程的创建和销毁成本很高，除此之外，线程的切换成本也是很高的。尤其在 Linux 这样的操作系统中，线程本质上就是一个进程，创建和销毁线程都是重量级的系统函数。如果并发访问量增加会导致线程数急剧膨胀可能会导致线程堆栈溢出、创建新线程失败等问题，最终导致进程宕机或者僵死，不能对外提供服务。

NIO 简介
NIO是一种同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，对应 java.nio 包，提供了 Channel , Selector，Buffer等抽象。

NIO中的N可以理解为Non-blocking，不单纯是New。它支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发。

通常来说NIO中的所有IO都是从 Channel（通道） 开始的。
从通道进行数据读取 ：创建一个缓冲区，然后请求通道读取数据。

从通道进行数据写入 ：创建一个缓冲区，填充数据，并要求通道写入数据。

1)Non-blocking IO（非阻塞IO）

IO流是阻塞的，NIO流是不阻塞的。

Java NIO使我们可以进行非阻塞IO操作。比如说，单线程中从通道读取数据到buffer，同时可以继续做别的事情，当数据读取到buffer中后，线程再继续处理数据。写数据也是一样的。另外，非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。

Java IO的各种流是阻塞的。这意味着，当一个线程调用 read() 或 write() 时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了

2)Buffer(缓冲区)

IO 面向流(Stream oriented)，而 NIO 面向缓冲区(Buffer oriented)。
Buffer是一个对象，它包含一些要写入或者要读出的数据。在NIO类库中加入Buffer对象，体现了新库与原I/O的一个重要区别。在面向流的I/O中·可以将数据直接写入或者将数据直接读到 Stream 对象中。虽然 Stream 中也有 Buffer 开头的扩展类，但只是流的包装类，还是从流读到缓冲区，而 NIO 却是直接读到 Buffer 中进行操作。
在NIO厍中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的; 在写入数据时，写入到缓冲区中。任何时候访问NIO中的数据，都是通过缓冲区进行操作。

3)Channel (通道)

NIO 通过Channel（通道） 进行读写。
通道是双向的，可读也可写，而流的读写是单向的。无论读写，通道只能和Buffer交互。因为 Buffer，通道可以异步地读写。

4)Selectors(选择器)

NIO有选择器，而IO没有。
选择器用于使用单个线程处理多个通道。因此，它需要较少的线程来处理这些通道。线程之间的切换对于操作系统来说是昂贵的。 因此，为了提高系统效率选择器是有用的。

通常来说NIO中的所有IO都是从 Channel（通道） 开始的。
从通道进行数据读取 ：创建一个缓冲区，然后请求通道读取数据。

从通道进行数据写入 ：创建一个缓冲区，填充数据，并要求通道写入数据。

线程状态

sleep() 方法是线程类（Thread）的静态方法，让调用线程进入睡眠状态，让出执行机会给其他线程，等到休眠时间结束后，线程进入就绪状态和其他线程一起竞争cpu的执行时间。
因为sleep() 是static静态的方法，他不能改变对象的机锁，当一个synchronized块中调用了sleep() 方法，线程虽然进入休眠，但是对象的机锁没有被释放，其他线程依然无法访问这个对象。

wait()是Object类的方法，当一个线程执行到wait方法时，它就进入到一个和该对象相关的等待池，同时释放对象的机锁，使得其他线程能够访问，可以通过notify，notifyAll方法来唤醒等待的线程

虚拟内存的基本思想：每个进程拥有自己独立的地址空间，这个空间被分为大小相等很多的块，称为页，每个页都是一段连续的地址。这些页被映射到物理内存，但并不是所有的页都需要在内存中程序才能运行。当程序引用到一部分在物理内存中的地址空间，由操作系统将缺失的部分装入物理内存并重新执行失败的命令。对于进程而言，逻辑上似乎有很大的内存空间，实际上其中一部分对应物理内存上的一块(称为帧，通常页和帧大小相等)，还有一些没加载在内存中的对应在硬盘上。
一、页式管理
页式管理的基本原理将各进程的虚拟空间划分成若干个长度相等的页(page)，页式管理把内存空间按页的大小划分成片或者页面（page frame），然后把页式虚拟地址与内存地址建立一一对应页表，并用相应的硬件地址变换机构，来解决离散地址变换问题。页式管理采用请求调页或预调页技术实现了内外存存储器的统一管理。
多级页表
块表TLB：提高访存性能的关键在于依靠页表的访问局部性。
二、段式管理的基本思想
把程序按内容或过程（函数）关系分成段，每段有自己的名字。一个用户作业或进程所包含的段对应一个二维线形虚拟空间，也就是一个二维虚拟存储器。段式管理程序以段为单位分配内存，然后通过地址影射机构把段式虚拟地址转换为实际内存物理地址。
段表：“内存首地址”和“段长”
三、段页式管理的实现原理
将用户程序分成若干段，并为每个段赋予一个段名。把每个段分成若干页
地址结构包括段号、段内页号和页内地址三部分

分页和分段的不同点：
目的不同：分页是由于系统管理的需要而不是用户的需要，它是信息的物理单位；分段的目的是为了能更好地满足用户的需要，它是信息的逻辑单位，它含有一组其意义相对完整的信息；
大小不同：页的大小固定且由系统决定，而段的长度却不固定，由其所完成的功能决定；
地址空间不同： 段向用户提供二维地址空间；页向用户提供的是一维地址空间；
信息共享：段是信息的逻辑单位，便于存储保护和信息的共享，页的保护和共享受到限制；
内存碎片：页式存储管理的优点是没有外碎片（因为页的大小固定），但会产生内碎片（一个页可能填充不满）；而段式管理的优点是没有内碎片（因为段大小可变，改变段大小来消除内碎片）。但段换入换出时，会产生外碎片（比如4k的段换5k的段，会产生1k的外碎片）。

页面置换算法
先进先出（FIFO）：把内存中驻留时间最久的页面置换算法予以淘汰
优点：先进先出算法实现简单，是最直观的一个算法
缺点：先进先出的性能最差，因为与通常页面的使用规则不符合，所以实际应用少
最近最久未使用（LRU）：选择最近且最久未被使用的页面进行淘汰
优点：由于考虑程序访问的时间局部性，一般能有较好的性能；实际应用多
缺点：实现需要较多的硬件支持，会增加硬件成本
最佳置换算法（OPT）
缺点：最佳置换算法是一种理想化算法，具有较好的性能，但是实际上无法实现（无法预知一个进程中的若干页面哪一个最长时间不被访问）；
优点：最佳置换算法可以保证获得最低的缺页率

DMA主要功能是传输数据，但是不需要占用CPU，即在传输数据时，CPU可以做别的事，像多线程。数据传输从外设到存储器或者从存储器到存储器。DMA控制器独立于内核，属于一个单独外设。

静态RAM速度是非常的快，不需要刷新电路即能保存它内部存储的数据。不像DRAM内存那样需要刷新电路，每隔一段时间，固定要对DRAM刷新充电一次，否则内部的数据即会消失，但是集成度低（存储相同的数据，静态RAM的体积是动态RAM的6倍），价格高（同容量的静态RAM是动态RAM的四倍），这样就有了一个折中的方法，不扩大原来的静态RAM缓存，而是增加一些高速动态RAM做为缓存，我们把原来的静态ram缓存叫一级缓存，而把后来增加的动态RAM叫二级缓存。 一般来说，每级缓存的命中率大概都在80%左右，只剩下20%的总数据量才需要从二级缓存、三级缓存或内存中读取。一级缓存和二级缓存中的内容都是内存中访问频率高的数据的复制品（映射），它们的存在都是为了减少高速CPU对慢速内存的访问。
主存和磁盘之间的数据交换不是以字节为单位的，而是以n个扇区为单位的（一个扇区有512字节），通常是4KB（8个扇区），8KB（16个扇区），16KB，……64KB为单位的

进程与线程的区别

进程是资源分配最小单位，线程是程序执行的最小单位；
进程有自己独立的地址空间，每启动一个进程，系统都会为其分配地址空间，建立数据表来维护代码段、堆栈段和数据段，线程没有独立的地址空间，它使用相同的地址空间共享数据；
CPU切换一个线程比切换进程花费小；
创建一个线程比进程开销小；
线程占用的资源要⽐进程少很多。
线程之间通信更方便，同一个进程下，线程共享全局变量，静态变量等数据，进程之间的通信需要以通信的方式进行；（但多线程程序处理好同步与互斥是个难点）
多进程程序更安全，生命力更强，一个进程死掉不会对另一个进程造成影响（源于有独立的地址空间），多线程程序更不易维护，一个线程死掉，整个进程就死掉了（因为共享地址空间）；
进程对资源保护要求高，开销大，效率相对较低，线程资源保护要求不高，但开销小，效率高，可频繁切换；
一个程序至少有一个进程，一个进程至少有一个线程，线程依赖于进程而存在；

进程控制块（PCB）：
1、进程控制块是进程存在的唯一标志；
2、是进程管理和控制的最重要的数据结构（进程标识符信息 、处理机状态信息、进程调度信息、进程控制信息）；
3、PCB的组织方式：链接方式（同一状态的PCB，依靠链接指针链接成队列），索引方式（同状态的PCB同样集中记录，但以索引表的方式记录PCB的地址）。

进程间的通信：
1.管道(pipe)及有名管道(named pipe)：
管道可用于具有亲缘关系的父子进程间的通信，它是半双工的（即数据只能在一个方向上流动），具有固定的读端和写端。有名管道除了具有管道所具有的功能外，它还允许无亲缘关系进程间的通信，FIFO有路径名与之相关联，它以一种特殊设备文件形式存在于文件系统中。
3.消息队列(message queue)：
消息队列是消息的链接表，它克服了上两种通信方式中信号量有限的缺点，具有写权限得进程可以按照一定得规则向消息队列中添加新信息；对消息队列有读权限得进程则可以从消息队列中读取信息。
4.共享内存(shared memory)：
可以说这是最有用的进程间通信方式。它使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据得更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。
5.信号量(semaphore)：
主要作为进程之间及同一种进程的不同线程之间得同步和互斥手段。
6.套接字(socket)；
这是一种更为一般得进程间通信机制，它可用于网络中不同机器之间的进程间通信，应用非常广泛。
2.信号(signal)：
信号是在软件层次上对中断机制的一种模拟，它是比较复杂的通信方式，用于通知进程有某事件发生，一个进程收到一个信号与处理器收到一个中断请求效果上可以说是一致的。

1. 管道：速度慢、容量有限 消息队列：容量收到系统限制，且要注意第一次读的时候，要考虑上一次没有读完数据的问题。
2. 信号量：不能传递复杂信息，只能用来同步。
3. 共享内存：能够很容易控制容量，速度快，但要保持同步，比如一个进程在写的时候，另一个进程要注意读写的问题，相当于线程中的线程安全。

线程之间的通信：
1.锁机制：互斥锁、条件变量、读写锁
　互斥锁提供了以排他方式防止数据结构被并发修改的方法。
　读写锁允许多个线程同时读共享数据，而对写操作是互斥的。
　条件变量可以以原子的方式进行阻塞进程，直到某个特定条件为真为止。对条件的测试是在互斥锁的保护下进行的。条件变量始终与互斥锁一起使用。
２.信号量机制：包括无名信号量和命名线程信号量
３.事件(信号)，Wait/Notify：通过通知操作的方式来保持多线程同步，还可以方便的实现多线程优先级的比较操作
线程间的通信目的主要是用于线程同步，所以线程没有像进程通信中的用于数据交换的通信机制。

互斥型信号量：必须是同一个任务申请，同一个任务释放，其他任务释放无效。同一个任务可以递归申请。(互斥信号量是二进制信号量的一个子集)
二进制信号量：一个任务申请成功后，可以由另一个任务释放。(与互斥信号量的区别)
整数型信号量：取值不局限于0和1,可以一个任务申请，另一个任务释放。(包含二进制信号量，二进制信号量是整数型信号量的子集)

二进制信号量实现任务互斥：
打印机资源只有一个，a bc三个任务共享，当a取得使用权后，为了防止其他任务错误地释放了信号量(二进制信号量允许其他任务释放)，必须将打印机房的门关起来(进入临界段)，用完后，释放信号量，再把门打开(出临界段)，其他任务再进去打印。(而互斥型信号量由于必须由取得信号量的那个任务释放，故不会出现其他任务错误地释放了信号量的情况出现，故不需要有临界段。互斥型信号量是二进制信号量的子集。)
二进制信号量实现任务同步：
a任务一直等待信号量，b任务定时释放信号量，完成同步功能
记录型信号量(record semaphore)：
每个信号量s除一个整数值value(计数)外，还有一个等待队列List，其中是阻塞在该信号量的各个线程的标识。当信号量被释放一个，值被加一后，系统自动从等待队列中唤醒一个等待中的线程，让其获得信号量，同时信号量再减一。

产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 占有且等待：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3）不可强行占有:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

解决死锁
一、死锁预防：破坏死锁的四个条件中的一个或几个。
(1)互斥：它是设备的固有属性所决定的，不仅不能改变，还应该加以保证。
(2)占有且等待：
为预防占有且等待条件，可以要求进程一次性的请求所有需要的资源，并且阻塞这个进程直到所有请求都同时满足。这个方法比较低效。
(3)不可抢占：
预防这个条件的方法：
如果占有某些资源的一个进程进行进一步资源请求时被拒绝，则该进程必须释放它最初占有的资源。
如果一个进程请求当前被另一个进程占有的一个资源，则操作系统可以抢占另外一个进程，要求它释放资源。
(4)循环等待：通过定义资源类型的线性顺序来预防。
如果一个进程已经分配了R类资源，那么接下来请求的资源只能是那些排在R类型之后的资源类型。该方法比较低效。

二、死锁避免：
两种死锁避免算法：
进程启动拒绝：如果一个进程的请求会导致死锁，则不启动该进程。
资源分配拒绝：如果一个进程增加的资源请求会导致死锁，则不允许此分配(银行家算法)。
银行家算法：
1.如果request<=need，转向步骤2；否则认为出错，因为请求资源大于需要资源。
2.如果request<=available，转向步骤3,；否则尚无足够资源，进程p阻塞；
3.系统尝试为把资源分配给进程P，并修改available、allocation和need的数值。
4.系统执行安全性算法，检查此次分配后系统是否处于安全状态，若安全，才正式将资源分配给进程P，否则将本次试探性分配作废，让进程P等待。
安全状态：系统能按照某种进程顺序，为每个进程分配资源，直至满足每个进程对资源的最大需求，使每个进程都可顺利完成。
安全性算法：
1.设置两个向量：
工作向量work：表示系统可提供给进程继续运行的所需的各类资源的数目，执行安全算法开始时，work=available。
finish：表示系统是否有足够资源分配给进程，使之运行完成。开始时先做finish[i]=false；当有足够资源分配给进程时再令finish[i]=true。
2.从进程集合找到一个满足下列条件的进程：
*finish[i]=false；
*need<=work；
*若找到执行步骤3；否则执行步骤4；
3.当进程P获得资源后，可顺利执行，直至完成，并释放出分配给它的资源，故应执行：
*work=work+allocation§；
*finish[i]=true；
*循环执行步骤2；
4.如果所有进程的finish=true，则表示系统处于安全状态；否则，系统处于不安全状态。

三、死锁检测算法：当任一进程Pj申请一个已被其他进程占用的资源ri时，进行死锁检测。检测算法通过反复查找进程等待表和资源分配表，来确定进程Pj对资源ri的请求是否导致形成环路，若是，便确定出现死锁。

四、死锁的解除：剥夺资源和撤销进程。

cpu调度算法
1.FCFS（先来先服务）无法保证周转时间，
2.SJF（短作业优先）这种方法周转时间最小。但是如果中间有个任务现在要执行，必须要等到前面的任务执行完才行，响应时间无法保证。
3.时间片轮状调度，每个任务分几个时间片，响应时间就可以保证。
4.优先级调度：优先高的进程，一直执行，可能会产生饥饿。

Linux常用命令
1.查看目录结构命令，ls(list)功能：列出目录内容
2.切换目录命令，cd(change directory)功能：切换目录
3.目录命令
pwd:显示当前工作目录
mkdir: 创建目录
4.文件浏览
cat 文件名：显示指定文件的所有内容（用于文件内容少的情况）
more 文件名：分页显示文件内容，还支持直接跳转行等功能（用于文件内容多的情况）
less 文件名 ：分页显示文件内容，操作更详细
tall命令：用来显示指定文件末尾内容，不指定文件时，作为输入信息进行处理。常用查看日志文件。
5.文件操作

1. 复制命令：cp，cp(copy)功能：复制文件或目录
2. 移动命令：mv，mv（move）功能：移动或更名现有的文件或目录
3. 删除命令：rm
4. 查找命令：find

7.管道
linux提供管道符号 “|” 作用是“命令1”的输出内容，将作为“命令2”的输入内容。一般与grep命令一起使用
grep命令：用于过滤/搜索特定字符。可使用正则表达式 能多种命令配合使用。
8.系统命令

1. ps命令：查看当前所有进程（包括执行ps命令的那个时刻进程信息）
2. kill命令：删除执行中的程序或工作
3. ifconfig命令：显示网络设备
   9.备份压缩：tar命令。-x 解开一个压缩文件的参数指令（extract）–解压
   10.文件权限：chmod命令
   Linux 权限格式：<类型><用户><组><其他用户>

网络

每层模型的职责
链路层：对0和1进行分组，定义数据帧，确认主机的物理地址，传输数据；
网络层：定义IP地址，确认主机所在的网络位置，并通过IP进行MAC寻址，对外网数据包进行路由转发；
传输层：定义端口，确认主机上应用程序的身份，并将数据包交给对应的应用程序；
应用层：定义数据格式，并按照对应的格式解读数据。
然后再把每层模型的职责串联起来，用一句通俗易懂的话讲就是：
当你输入一个网址并按下回车键的时候，首先，应用层协议对该请求包做了格式定义；紧接着传输层协议加上了双方的端口号，确认了双方通信的应用程序；然后网络协议加上了双方的IP地址，确认了双方的网络位置；最后链路层协议加上了双方的MAC地址，确认了双方的物理位置，同时将数据进行分组，形成数据帧，采用广播方式，通过传输介质发送给对方主机。而对于不同网段，该数据包首先会转发给网关路由器，经过多次转发后，最终被发送到目标主机。目标机接收到数据包后，采用对应的协议，对帧数据进行组装，然后再通过一层一层的协议进行解析，最终被应用层的协议解析并交给服务器处理。

链路层
网络通信就是把有特定意义的数据通过物理介质传送给对方，单纯的发送 0 和 1 是没有意义的，要传输有意义的数据，就需要以字节为单位对 0 和 1 进行分组，并且要标识好每一组电信号的信息特征，然后按照分组的顺序依次发送。以太网规定一组电信号就是一个数据包，一个数据包被称为一帧， 制定这个规则的协议就是以太网协议。一个完整的以太网数据包由首部、数据和尾部三部分组成，首部包含了目标MAC地址、源MAC地址和类型；数据最短为46个字节，最长为1500个字节，如果需要传输的数据很长，就必须分割成多个帧进行发送；尾部固定为4个字节，表示数据帧校验序列，用于确定数据包在传输过程中是否损坏。
以太网规协议定，接入网络的设备都必须安装网络适配器，即网卡， 数据包必须是从一块网卡传送到另一块网卡。而网卡地址就是数据包的发送地址和接收地址，也就是帧首部所包含的MAC地址，MAC地址是每块网卡的身份标识，就如同我们身份证上的身份证号码，具有全球唯一性。
有了MAC地址以后，以太网采用广播形式，把数据包发给该子网内所有主机，子网内每台主机在接收到这个包以后，都会读取首部里的目标MAC地址，然后和自己的MAC地址进行对比，如果相同就做下一步处理，如果不同，就丢弃这个包。
所以链路层的主要工作就是对电信号进行分组并形成具有特定意义的数据帧，然后以广播的形式通过物理介质发送给接收方。

网络层
对于上面的过程，有几个细节问题值得我们思考：
发送者如何知道接收者的MAC地址？
发送者如何知道接收者和自己同属一个子网？
如果接收者和自己不在同一个子网，数据包如何发给对方？
为了解决这些问题，网络层引入了三个协议，分别是IP协议、ARP协议、路由协议。
【1】IP协议
通过前面的介绍我们知道，MAC地址只与厂商有关，与所处的网络无关，所以无法通过MAC地址来判断两台主机是否属于同一个子网。
因此，网络层引入了IP协议，制定了一套新地址，使得我们能够区分两台主机是否同属一个网络，这套地址就是网络地址，也就是所谓的IP地址。
IP地址目前有两个版本，分别是IPv4和IPv6，IPv4是一个32位的地址，常采用4个十进制数字表示。IP协议将这个32位的地址分为两部分，前面部分代表网络地址，后面部分表示该主机在局域网中的地址。由于各类地址的分法不尽相同，以C类地址192.168.24.1为例，其中前24位就是网络地址，后8位就是主机地址。因此， 如果两个IP地址在同一个子网内，则网络地址一定相同。为了判断IP地址中的网络地址，IP协议还引入了子网掩码， IP地址和子网掩码通过按位与运算后就可以得到网络地址。
由于发送者和接收者的IP地址是已知的(应用层的协议会传入)， 因此我们只要通过子网掩码对两个IP地址进行AND运算后就能够判断双方是否在同一个子网了。
【2】ARP协议
即地址解析协议，是根据IP地址获取MAC地址的一个网络层协议。其工作原理如下：
ARP首先会发起一个请求数据包，数据包的首部包含了目标主机的IP地址，然后这个数据包会在链路层进行再次包装，生成以太网数据包，最终由以太网广播给子网内的所有主机，每一台主机都会接收到这个数据包，并取出标头里的IP地址，然后和自己的IP地址进行比较，如果相同就返回自己的MAC地址，如果不同就丢弃该数据包。ARP接收返回消息，以此确定目标机的MAC地址；与此同时，ARP还会将返回的MAC地址与对应的IP地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。cmd输入 arp -a 就可以查询本机缓存的ARP数据。
【3】路由协议
通过ARP协议的工作原理可以发现，ARP的MAC寻址还是局限在同一个子网中，因此网络层引入了路由协议，首先通过IP协议来判断两台主机是否在同一个子网中，如果在同一个子网，就通过ARP协议查询对应的MAC地址，然后以广播的形式向该子网内的主机发送数据包；如果不在同一个子网，以太网会将该数据包转发给本子网的网关进行路由。网关是互联网上子网与子网之间的桥梁，所以网关会进行多次转发，最终将该数据包转发到目标IP所在的子网中，然后再通过ARP获取目标机MAC，最终也是通过广播形式将数据包发送给接收方。
而完成这个路由协议的物理设备就是路由器，在错综复杂的网络世界里，路由器扮演者交通枢纽的角色，它会根据信道情况，选择并设定路由，以最佳路径来转发数据包。
【4】IP数据包
在网络层被包装的数据包就叫IP数据包，IP数据包由首部和数据两部分组成，首部长度为20个字节，主要包含了目标IP地址和源IP地址，目标IP地址是网关路由的线索和依据；数据部分的最大长度为65515字节，理论上一个IP数据包的总长度可以达到65535个字节，而以太网数据包的最大长度是1500个字符，如果超过这个大小，就需要对IP数据包进行分割，分成多帧发送。
所以，网络层的主要工作是定义网络地址，区分网段，子网内MAC寻址，对于不同子网的数据包进行路由.

http报文格式


100~199（信息性状态码）
200~299（成功）
300~399（重定向）
400~499（客户端错误）
500~599（服务器端错误）

tcp报文格式

序号: 一次TCP通信 (从TCP连接建立到断开) 过程中某一个传输方向上的字节流的每个字节的编号.假设主机A和主机B进行TCP通信,A发送给B的第一个TCP报文段中, 序号值被系统初始化为某个随机值ISN (初始序号值). 那么在该传输方向上(从A到B), 后续的TCP报文段中序号值将被系统设置成ISN 加上该报文段所携带数据的第一个字节在整个字节流中的偏移.例如,某个TCP报文段传送的数据是字节流中的第1025~2048字节,那么该报文段的序号值就是ISN+1025.另外一个传输方向(从B到A)的TCP报文段的序号值也具有相同的含义.
确认号: 用作对另一方发送来的TCP报文段的响应.其值是收到的TCP报文段的序号值加1.假设主机A和主机B进行TCP通信,那么A发送出的TCP报文段不仅携带自己的序号,而且包含对B发送来的TCP报文段的确认号.反之,B发送出的TCP报文段也同时携带自己的序号和对A发送来的报文段的确认号.
4位头部长度 : 标识该TCP头部有多少个32bit字 (4字节). 因为4位最大能表示15,所以TCP头部最长是60字节.

URG 表示紧急指针 (urgent pointer) 是否有效.
ACK 表示确认号是否有效. 我们称携带ACK标志的 TCP报文段为确认报文段.
(确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1)
PSH 提示接收端应用程序应该立即从 TCP接收缓冲区中读走数据,为接收后续数据腾出空间 (如果应 用程序不将接收到的数据 读 走, 它们就会一直停留在TCP接收缓冲区中).
RST 表示要求对方重新建立连接.我们称携带RST标志的 TCP报文段为复位报文段.
SYN 表示请求建立一个连接. 我们称携带 SYN 标志的TCP报文段为同步报文段.
(同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1)
F I N 表示通知对方本端要关闭连接了.我们称携带FIN标志的TCP报文段为结束报文段.
(终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接)

窗口大小:是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

16位校验和:由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障，窗口大小是一个16bit字段，因而窗口大小最大为65535。

16位紧急指针:是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。例如，已经发送了很长的一个程序在远地的主机上运行。但后来发现了一些问题，需要取消该程序的运行

15.选项：长度可变，最长可达40字节。当没有使用“选项”时，TCP的首部长度是20字节。
1）MSS 最大报文段长度
MSS最大报文段长度（数据字段的最大长度，默认是536字节）。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。
因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS接入这一字段，以后就按照这个数值传送数据。

udp报文格式

慢开始、快重传、拥塞避免

快重传：
快重传算法要求首先接收方收到一个失序的报文段后就立刻发出重复确认，而不要等待自己发送数据时才进行捎带确认。接收方成功的接受了发送方发送来的M1、M2并且分别给发送了ACK，现在接收方没有收到M3，而接收到了M4，显然接收方不能确认M4，因为M4是失序的报文段。如果根据可靠性传输原理接收方什么都不做，但是按照快速重传算法，在收到M4、M5等报文段的时候，不断重复的向发送方发送M2的ACK,如果接收方一连收到三个重复的ACK,那么发送方不必等待重传计时器到期，由于发送方尽早重传未被确认的报文段。

GET和POST的区别

GET方法的数据参数是暴露在起始行的URL中的，而POST方法的数据参数是在报文主体中的。
GET方法相对来说没有POST安全，因为它的数据参数可以直接从URL中获取，但是GET的效率更高。
GET方法的数据参数大小有一定的限制（1024）（原因也是因为它的数据参数是放在URL中的），而POST对数据大小是没有限制的。
POST有两个数据包 100->发data->200

TCP和UDP
TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。TCP 数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常 TCP 数据包的长度不会超过IP数据包的长度，以确保单个 TCP 数据包不必再分割。

UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文（segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文，而ip头中有一个TTL域，TTL是time to live的缩写，中文可以译为“生存时间”，这个生存时间是由源主机设置初始值但不是存的具体时间，而是存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。

三次握手
三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。进行三次握手：
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。
首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

三次握手：
第一次握手：客户端发送网络包，服务端收到了。
这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。
两次握手会出现下面这种情况：
如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

半连接队列
服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

ISN(Initial Sequence Number)
当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。
三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

SYN攻击
第三次握手的时候可以携带数据。第一次、第二次握手不可以携带数据
假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。
也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

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

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。
常见的防御 SYN 攻击的方法有如下几种：缩短超时（SYN Timeout）时间、增加最大半连接数、过滤网关防护、SYN cookies技术

TCP第三次握手时ACK丢失
如果此时ACK在网络中丢失，那么Server端该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。 如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。
但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包(用于强制关闭tcp连接)响应，方能感知到Server的错误。

流量控制

1. 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值.
2. 发送窗口内字段的时候, 不需要等待任何ACK, 直接发送;
3. 收到第一个ACK后, 滑动窗口向后移动, 继续发送下一个窗口字段的数据; 依次类推;
4. 操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
5. 窗口越大, 则网络的吞吐率就越高
   当在前面还有字节未接收，但收到后面的字节的情况下，窗口是不会移动的，并不对后续字节确认，以此确保对端会对这些数据进行重传
   窗口大小不能大于序号空间大小的一半。目的是为了不让两个窗口出现交迭，比如总大小为7，窗口大小都为4，接收窗口应当滑动4，但只剩3个序号，导致两个窗口交迭。

糊涂窗口综合症
1.TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取为1个字节（这样就使接收缓存空间仅腾出1个字节）
2.然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40字节长：20字节的IP头+20字节的TCP头）。
3.接收方发回确认，仍然将窗口设置为1个字节。
4.这样进行下去，使网络的效率很低。
解决糊涂窗口综合证
1.让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。
2.只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。
3.此外。发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。
发送端：Nagle算法禁用：使用TCP套接字选项TCP_NODELAY可以关闭套接字选项
1.若发送应用进程把要求发送的数据逐个地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。
2.当发送方收到第一个数据字节的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存，只有在收到对前一个报文段的确认后才继续发送下一个报文段。
3.当数据到达较快而网络速率较慢时，用这养的方法可明显减少所用的网络带宽。
4.Nagle算法还规定，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样就可以有效的提高网络的吞吐量。
接收端：延迟ACK
如果tcp对每个数据包都发送一个ack确认，那么只是一个单独的数据包为了发送一个ack代价比较高，所以tcp会延迟一段时间，如果这段时间内有数据发送到对端，则捎带发送ack，如果在延迟ack定时器触发时候，发现ack尚未发送，则立即单独发送；
延迟ACK好处：
(1) 避免糊涂窗口综合症；
(2) 发送数据的时候将ack捎带发送，不必单独发送ack；
(3) 如果延迟时间内有多个数据段到达，那么允许协议栈发送一个ack确认多个报文段；
问题
试想如下典型操作，写-写-读，即通过多个写小片数据向对端发送单个逻辑的操作，两次写数据长度小于MSS，当第一次写数据到达对端后，对端延迟ack，不发送ack，而本端因为要发送的数据长度小于MSS，所以nagle算法起作用，数据并不会立即发送，而是等待对端发送的第一次数据确认ack；这样的情况下，需要等待对端超时发送ack，然后本段才能发送第二次写的数据，从而造成延迟；
死锁
当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。
为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。
tcp粘包
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段；
站在传输层的角度, TCP是一个一个报文过来的，按照序号排好序放在缓冲区中；
站在应用层的角度, 看到的只是一串连续的字节数据. 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。
那么如何避免粘包问题，明确两个包之间的边界呢？
1.对于定长的包, 保证每次都按固定大小读取即可;
2.对于变长的包, 可以在报头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
3.对于变长的包, 还可以在包和包之间使用明确的分隔符。
4.TLV格式的数据传输

后退n协议（GBN）
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。

四次挥手
刚开始双方都处于ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

1. 客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
2. 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
3. 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
4. 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

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

2MSL等待状态
TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。
客户端发送的ACK segment存活期1MSL,服务端重发FIN segment存活期1MSL，加一起2MSL。2MSL是一个临界值，利用尽量大的等待时间来确保TCP连接断开的可靠性。

两个理由：

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

输入一个url到最终界面打开的过程

https

非对称加密（SSH协议）
非对称加密使用一对密钥：一把叫做私钥，另一把叫做公钥。顾名思义，私钥不能让其他任何人知道，而公钥则可以随意发布，任何人都可以获得。

发送密文的一方使用对方的公钥进行加密处理，对方收到被加密的信息后，再使用自己的私钥进行解密。利用这种方式，不需要发送用来解密的私钥，也不必担心密钥被攻击者窃听而盗走。

非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

这种方式有以下缺点：
公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容。
公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改。
使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率。

对称加密+非对称加密(HTTPS采用这种方式)
发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

解决报文可能遭篡改问题——数字签名
网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？校验数字签名。
数字签名有两种功效：
确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名；确定消息的完整性,证明数据是否未被篡改过。

发送者生成数字签名：将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。
接收者校验数字签名：接收者用发送者的公钥解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过。

这个过程的前提是客户端要知道服务器端的公钥。问题的关键的是，和消息本身一样，服务器端的公钥不能在不安全的网络中直接发送给客户端，或者说客户端拿到的公钥如何证明是服务器端的。
此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，客户端内置了所有受信任CA的证书。CA对服务器端的公钥（和其他信息）数字签名后生成证书。

解决通信方身份可能被伪装的问题—数字证书
数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。如下：

服务器端的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名;
客户端向服务器端发出请求时，服务器返回证书文件;
客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
客户端还会验证证书相关的域名信息、有效时间等信息；客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。

浏览器发起一个HTTPS的请求。
服务器端把事先配置好的公钥证书返回给客户端。
浏览器验证公钥证书：比如是否在有效期内，证书的用途是不是匹配客户端请求的站点，如果验证通过则继续，不通过则显示警告信息。
浏览器使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给服务器。
服务器使用自己的私钥解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
服务器使用对称密钥对浏览器第一次请求URL对应的响应进行加密，发送给浏览器。
此后浏览器和服务器都使用这个对称密钥进行通信。

RSA算法
将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。
生成公钥和私钥
1、随机生成两个随机素数P，Q
2、将P、Q两个素数相乘得到一个数N，即N=PQ（需要公开）
3、将P、Q分别减1再相乘得到一个数T，即T=(P-1)(Q-1)
4、选择一个数E，E满足和T互质且E小于T
5、根据DE mod T = 1计算出密钥D
6、通过以上步骤可以得到N，E，D这3个数字，其中（N、E）作为公钥，（N、D）作为私钥（公钥和私钥可以互换）

cookies
一、cookie机制和session机制的区别
　　具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
　　程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为地在请求的URL后面附加上一个JSESSION的参数)。
　　如果客户请求不包含session id，则为此客户创建一个session并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给客户端保存。
　　在服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的。
二、会话cookie和持久cookie的区别
　　如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
　　如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
　　存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。
三、如何利用实现自动登录
　　当用户在某个网站注册后，就会收到一个惟一用户ID的cookie。客户后来重新连接时，这个用户ID会自动返回，服务器对它进行检查，确定它是否为注册用户且选择了自动登录，从而使用户无需给出明确的用户名和密码，就可以访问服务器上的资源。
四、如何根据用户的爱好定制站点
　　网站可以使用cookie记录用户的意愿。对于简单的设置，网站可以直接将页面的设置存储在cookie中完成定制。然而对于更复杂的定制，网站只需仅将一个惟一的标识符发送给用户，由服务器端的数据库存储每个标识符对应的页面设置。
五、禁用cookie：
如果客户端禁用了cookie，通常有两种方法实现session而不依赖cookie。
1）URL重写，就是把sessionId直接附加在URL路径的后面。
2）表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：

java

红黑树：treeset、拉链法、linux进程调度；
b树：数据库、文件系统；
b+树：mysql。
java集合

String StringBuffer StringBuilder
String的值是不可变的
StringBuffer是可变类，和线程安全的字符串操作类，每个StringBuffer对象都有一定的缓冲区容量，当字符串大小没有超过容量时，不会分配新的容量，当字符串大小超过容量时，会自动增加容量。线程安全，多线程操作字符串？
StringBuilder 线程不安全，单线程操作字符串？

hashmap

Map 是 Key-Value 对映射的抽象接口，该映射不包括重复的键，即一个键对应一个值。HashMap 是 Java Collection Framework 的重要成员，也是Map族中我们最为常用的一种。简单地说，HashMap 是基于哈希表的 Map 接口的实现，以 Key-Value 的形式存在，即存储的对象是 Entry (同时包含了 Key 和 Value) 。在HashMap中，其会根据hash算法来计算key-value的存储位置并进行快速存取。特别地，HashMap最多只允许一条Entry的键为Null(多条会覆盖)。此外，HashMap 是 Map 的一个非同步的实现。一般如果new HashMap() 不传值，默认大小是16，负载因子是0.75， 如果自己传入初始大小k，初始化大小为 大于k的 2的整数次方，例如如果传10，大小为16。

当我们调用put方法存值时，HashMap首先会调用Key的hashCode方法，然后基于此获取Key哈希码，通过哈希码快速找到某个桶，这个位置可以被称之为 bucketIndex。如果两个对象的hashCode不同，那么equals一定为 false；否则，如果其hashCode相同，equals也不一定为 true。所以，理论上，hashCode 可能存在碰撞的情况，当碰撞发生时，这时会取出bucketIndex桶内已存储的元素，并通过hashCode() 和 equals() 来逐个比较以判断Key是否已存在。如果已存在，则使用新Value值替换旧Value值，并返回旧Value值；如果不存在，则存放新的键值对到桶中。因此，在 HashMap中，equals() 方法只有在哈希码碰撞时才会被用到。
Object类的hashCode方法返回的hash值其实是对象的内存地址。

hash() 方法用于对Key的hashCode进行重新计算，为了防止质量低下的hashCode()函数实现。由于hashMap的支撑数组长度总是 2 的幂次，通过右移可以使低位的数据尽量的不同，从而使hash值的分布尽量均匀。因为key.hashCode()函数调用的是key键值类型自带的哈希函数，返回int型散列值。int值范围为-2147483648~2147483647，前后加起来大概40亿的映射空间。只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个40亿长度的数组，内存是放不下的。你想，如果HashMap数组的初始大小才16，用之前需要对数组的长度取模运算，得到的余数才能用来访问数组下标。另外Java1.8相比1.7做了调整，1.7做了四次移位和四次异或，但明显Java 8觉得扰动做一次就够了，做4次的话，多了可能边际效用也不大，所谓为了效率考虑就改成一次了。
而 indexFor() 方法用于生成这个Entry对象的插入位置。当计算出来的hash值与hashMap的(length-1)做了&运算后，会得到位于区间[0，length-1]的一个值。特别地，这个值分布的越均匀， HashMap 的空间利用率也就越高，存取效率也就越好。

 static int hash(int h) {
        h ^= (h >>> 20) ^ (h >>> 12);
        return h ^ (h >>> 7) ^ (h >>> 4);
    }
static int indexFor(int h, int length) {
        return h & (length-1);  // 作用等价于取模运算，但这种方式效率更高
    }

为什么容量总是为2的n次幂
HashMap是根据key的hash值决定key放到哪个桶中，通过tab[i = (n - 1) & hash]公式计算得出；这里的n是HashMap的容量，因为n永远是2的次幂，所以n - 1通过二进制表示，永远都是末尾连续1的形式表示（如00001111、00000011），当(n - 1) 和hash做与运算时，会保留hash中后x位的1：例如00001111 & 10000011 = 00000011
好处在于：&运算速度快，至少比%取模运算快；能保证索引值肯定在HashMap的容量大小范围内；(n - 1) & hash的值是均匀分布的，可以减少hash冲突

1.8还有三点主要的优化：

数组+链表改成了数组+链表或红黑树；
链表的插入方式从头插法改成了尾插法，简单说就是插入时，如果数组位置上已经有元素，1.7将新元素放到数组中，原始节点作为新节点的后继节点，1.8遍历链表，将元素放置到链表的最后；
扩容的时候1.7需要对原数组中的元素进行重新hash定位在新数组的位置，1.8采用更简单的判断逻辑，位置不变或索引+旧容量大小；
在插入时，1.7先判断是否需要扩容，再插入，1.8先进行插入，插入完成再判断是否需要扩容；

为什么要做这几点优化；

防止发生hash冲突，链表长度过长，将时间复杂度由O(n)降为O(logn);

因为1.7头插法扩容时，头插法会使链表发生反转，多线程环境下会产生环；或多线程put的时候可能导致元素丢失
（主要问题出在addEntry方法的new Entry (hash, key, value, e)，如果两个线程都同时取得了e,则他们下一个元素都是e，然后赋值给table元素的时候有一个成功有一个丢失。）

put非null元素后get出来的却是null

A线程在插入节点B，B线程也在插入，遇到容量不够开始扩容，重新hash，放置元素，采用头插法，后遍历到的B节点放入了头部，这样形成了环。hashmap多线程扩容死循环细节
扩容的时候为什么1.8 不用重新hash就可以直接定位原节点在新数据的位置呢?

这是由于扩容是扩大为原数组大小的2倍，用于计算数组位置的掩码仅仅只是高位多了一个1，怎么理解呢？

扩容前长度为16，用于计算(n-1) & hash 的二进制n-1为0000 1111，扩容为32后的二进制就高位多了1，为0001 1111。

因为是& 运算，1和任何数 & 都是它本身，那就分二种情况，如下图：原数据hashcode高位第4位为0和高位为1的情况；

第四位高位为0，重新hash数值不变，第四位为1，重新hash数值比原来大16（旧数组的容量）

TreeMap是按照Key的自然顺序或者Comprator的顺序进行排序，内部是通过红黑树来实现。所以要么key所属的类实现Comparable接口，或者自定义一个实现了Comparator接口的比较器，传给TreeMap用于key的比较。

红黑树
每个节点要么是红色，要么是黑色；
根节点永远是黑色的；
所有的叶节点都是是黑色的（注意这里说叶子节点其实是上图中的 NIL 节点）；
每个红色节点的两个子节点一定都是黑色；
从任一节点到其子树中每个叶子节点的路径都包含相同数量的黑色节点；

arraylist扩容
如果通过无参构造的话，初始数组容量为0，当真正对数组进行添加时，才真正分配容量。每次按照1.5倍（位运算）的比率通过copeOf的方式扩容。 在JKD1.6中实现是，如果通过无参构造的话，初始数组容量为10，每次通过copeOf的方式扩容后容量为原来的1.5倍。
stringbuild扩容
不声明长度,使用无参构造方法创建实例对象时,会调用父类的构造方法创建一个默认初识容量为16的char[]数组；使用有参构方法传入字符串,初始化实例对象时，初始长度为当前字符串长度 + 16；扩容时先将新容量扩大到value的长度乘以2加2，如果不够则直接扩充到所需的容量大小。
在使用StringBuilder的append()之后，我们一般会在后面在加上一个分隔符，例如逗号，也就是再加上一个char，而char在java中占2个字节，避免了因为添加分隔符而再次引起扩容。

构造方法
直接定址法：f=a*k+b；
数字分析法：事先知道关键字的集合，且每个关键字的位数比哈希表的地址码位数多时，可以从关键字中选出分布比较均匀的若干位，构成哈希地址。
平方取中法：当无法确定关键字中哪几位分布比较均匀时，可以先求出关键字的平方值的中间几位作为哈希地址
分段叠加法：按哈希表的地址位数将关键字分成位数相等的几部分（最后一部分较短），然后将这几部分相加，舍弃最高位后的结果就是该关键字的哈希地址。
除留余数法：假设哈希表长为 m,p为小于等于 m 的 最大数数，则哈希 函数为 H(k) = k%p
伪随机数法：采用一个伪随机函数作为哈希函数，即 H(key) = random(key)
冲突解决方法
开放定址法（线性探测再散列、二次探测再散列、伪随机探测再散列）
再哈希法
建立一个公共溢出区

继承和抽象类
1）抽象类可以提供成员方法的实现细节，而接口中只能存在public abstract 方法；
2）抽象类中的成员变量可以是各种类型的，但不能是private。因为一个抽象方法需要在子类中实现，但private无法访问子类，因此不抽象类不可能存在private属性。而接口中的成员变量只能是public static final类型的；
3）接口中不能含有静态代码块以及静态方法，而抽象类可以有静态代码块和静态方法；
4）一个类只能继承一个抽象类，而一个类却可以实现多个接口。

java运行
c++直接编译成机器码可直接运行在机器上
.java文件，需要通过javac编译，产生.class文件（JVM主要由三部分组成：类加载器、运行时数据区和执行引擎），虚拟机将class文件加载到方法区，在java运行过程当中执行方法，就会从方法区中取，虚拟机会为当前线程的栈中生成栈帧，栈帧负责存储局部变量和字节码操作数，退出当前方法栈帧就会退出。
加载是类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
1）通过一个类的全限定名来获取其定义的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。
ClassLoader使用的是双亲委托模型来搜索类的，每个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个包含的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。当一个ClassLoader实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。

currentHashMap
ConcurrentHashMap使用分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。

在JDK1.7中ConcurrentHashMap采用了数组+Segment+分段锁的方式实现。
采用Segment(分段锁)来减少锁的粒度，ConcurrentHashMap中的分段锁称为Segment，它类似于HashMap的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表,同时又是一个ReentrantLock（Segment继承了ReentrantLock）。Segment默认是16，按理说最多同时支持16个线程并发读写，初始化时也可以指定Segment数量，每一个Segment都会有一把锁，保证线程安全。
ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作。第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部。
该结构的优劣势
1、坏处是这一种结构的带来的副作用是Hash的过程要比普通的HashMap要长。
2、好处是写操作的时候可以只对元素所在的Segment进行加锁即可，不会影响到其他的Segment，这样，在最理想的情况下，ConcurrentHashMap可以最高同时支持Segment数量大小的写操作（刚好这些写操作都非常平均地分布在所有的Segment上）。

JDK1.8对ConcurrentHashMap加锁方式进行了优化，它抛弃了JDK1.6中分段锁的设计，而是直接对Map中Table数组的每个节点进行加锁，进一步减少了锁粒度，并且不再采用ReentrantLock加锁 ，直接使用synchronized同步块（JDK1.6开始已经对synchronized 做了大量优化，加入了自旋锁、偏向锁、轻量级锁、重量级锁等）。CSA
为了提高查询效率，采用了数组+链表+红黑树的设计，当链表中的元素个数大于64，且数组中链表节点长度大于8，则会自动把链表转化为红黑树，当两个条件有一个不满足时，会回退到数组+单链表的数据结构。

插入数据节点的过程：
首先是根据key的hashCode做一次重哈希（进一步减少哈希碰撞）
先判断table为空，空则初始化Map，否则：
根据hashCode取模定位到table中的某个节点f，如果f为空，则新创建一个节点，使用cas方式更新到数组的f节点上，插入结束，
transfer数据转移过程可以分为如下几个步骤：
第一个扩容线程进来后创建nextTable数组，并设置transferIndex；
线程（第一个或其他）通过transferIndex-stride（扩容步长）来领取一个扩容子任务，transferIndex减到0说明所有子任务领取完成；
线程领取到扩容子任务后设置当前处理子任务的下界并更新当前处理节点所在的索引位置；
对子任务中的每个节点，扩容线程从后向前依次判断该节点是否已经转移，如果没有转移，则对该节点进行加锁，并且把节点对应的链表或红黑树转移到新数组nextTable中去；
如果线程处理的节点索引已经到达子任务的下界，则子任务执行结束，并尝试去领取新的子任务，若领取不到再判断当前线程是否是最后一个扩容线程，若是则最后扫描一遍数组，执行清理工作，否则直接退出。

1.7size 计算是先采用不加锁的方式，连续计算元素的个数，
最多计算 3 次：1、如果前后两次计算结果相同，则说明计算出来的元素个数是准确的；2、如果
前后两次计算结果都不同，则给每个 Segment 进行加锁，再计算一次元素的个数；
1.8 中放弃了 Segment 臃肿的设计，取而代之的是采用 Node + CAS + Synchronized 来
保证并发安全进行实现，1.8 中使用一个 volatile 类型的变量 baseCount 记录元素的个数，当
插入新数据或则删除数据时，会通过 addCount()方法更新 baseCount，通过累加 baseCount 和
CounterCell 数组中的数量，即可得到元素的总个数；

多线程实现：
1、继承Thread类
实现方式很简单，只需要创建一个类去继承Thread类然后重写run方法，在main方法中调用该类实例对象的start方法即可实现多线程并发。代码：
调用start()方法是告诉CPU此线程已经准备就绪可以执行，进而系统有时间就会来执行其run()方法。而直接调用run()方法，则不是异步执行，而是等同于调用函数般按顺序同步执行，这就失去了多线程的意义了。
2、实现Runnable接口
这种方式的实现也很简单，就是把继承Thread类改为实现Runnable接口。
3、使用Callable和Future创建线程
获取子线程的返回值；run方法可以抛出异常
Future异步通过get()方法得到结果，get方法会阻塞直到结果准备好了。如果想取消，可调用cancel()方法。
4、使用线程池（有返回值）
①newSingleThreadExecutor：单个线程的线程池，即线程池中每次只有一个线程工作，单线程串行执行任务
②newFixedThreadExecutor(n)：固定数量的线程池，没提交一个任务就是一个线程，直到达到线程池的最大数量，然后后面进入等待队列直到前面的任务完成才继续执行
③newCacheThreadExecutor（推荐使用）：可缓存线程池，当线程池大小超过了处理任务所需的线程，那么就会回收部分空闲（一般是60秒无执行）的线程，当有任务来时，又智能的添加新线程来执行。
④newScheduleThreadExecutor：大小无限制的线程池，支持定时和周期性的执行线程
一、corePoolSize 线程池核心线程大小
二、maxPoolSize 线程池最大线程数量
三、keepAliveTime 空闲线程存活时间：当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize；如果allowCoreThreadTimeout=true，则会直到线程数量=0
四、queueCapacity：任务队列容量（阻塞队列）：当核心线程数达到最大时，新任务会放在队列中排队等待执行
五、workQueue 工作队列：新任务被提交后，会先进入到此工作队列中，任务调度时再从队列中取出任务。jdk中提供了四种工作队列：
①ArrayBlockingQueue
基于数组的有界阻塞队列，按FIFO排序。新任务进来后，会放到该队列的队尾，有界的数组可以防止资源耗尽问题。当线程池中线程数量达到corePoolSize后，再有新任务进来，则会将任务放入该队列的队尾，等待被调度。如果队列已经是满的，则创建一个新线程，如果线程数量已经达到maxPoolSize，则会执行拒绝策略。
②LinkedBlockingQuene
基于链表的无界阻塞队列（其实最大容量为Interger.MAX），按照FIFO排序。由于该队列的近似无界性，当线程池中线程数量达到corePoolSize后，再有新任务进来，会一直存入该队列，而不会去创建新线程直到maxPoolSize，因此使用该工作队列时，参数maxPoolSize其实是不起作用的。
③SynchronousQuene
一个不缓存任务的阻塞队列，生产者放入一个任务必须等到消费者取出这个任务。也就是说新任务进来时，不会缓存，而是直接被调度执行该任务，如果没有可用线程，则创建新线程，如果线程数量达到maxPoolSize，则执行拒绝策略。
④PriorityBlockingQueue
具有优先级的无界阻塞队列，优先级通过参数Comparator实现。
六、handler 拒绝策略：两种情况会拒绝处理任务：当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务；当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务
①CallerRunsPolicy
该策略下，在调用者线程中直接执行被拒绝任务的run方法，除非线程池已经shutdown，则直接抛弃任务。
②AbortPolicy
该策略下，直接丢弃任务，并抛出RejectedExecutionException异常。
③DiscardPolicy
该策略下，直接丢弃任务，什么都不做。
④DiscardOldestPolicy
该策略下，抛弃进入队列最早的那个任务，然后尝试把这次拒绝的任务放入队列

Timer需要和TimerTask配合使用，才能完成调度功能。Timer表示调度器，TimerTask表示调度器执行的任务。

线程同时执行
1、wait()，然后使用notifyAll；
2、CyclicBarrier 和CountDownLatch每个线程调用await方法阻塞主线程直到N减少到0。
CountDownLatch：一个或者多个线程，等待其他多个线程完成某件事情之后才能执行；
CyclicBarrier：多个线程互相等待，直到到达同一个同步点，再继续一起执行。
对于CountDownLatch来说，重点是“一个线程（多个线程）等待”，而其他的N个线程在完成“某件事情”之后，可以终止，也可以等待。而对于CyclicBarrier，重点是多个线程，在任意一个线程没有完成，所有的线程都必须等待。
CountDownLatch是计数器，线程完成一个记录一个，只不过计数不是递增而是递减，而CyclicBarrier更像是一个阀门，需要所有线程都到达，阀门才能打开，然后继续执行。

主线程等待其余线程结束再执行
①、t1.join()
②、while(t1.isAlive())
③、while(Thread.activeCount()>1)
④、ExecutorService fixedThreadPool = Executors.newFixedThreadPool(5);fixedThreadPool.shutdown();fixedThreadPool.isTerminated();
④、CountDownLatch

终止线程
1、使用退出标志volatile，使线程正常退出，也就是当 run() 方法完成后线程中止。
2、使用 stop() 方法强行终止线程，但是不推荐使用这个方法，该方法已被弃用。
调用 stop() 方法会立刻停止 run() 方法中剩余的全部工作，包括在 catch 或 finally 语句中的，并抛出ThreadDeath异常(通常情况下此异常不需要显示的捕获)，因此可能会导致一些清理性的工作的得不到完成，如文件，数据库等的关闭。
调用 stop() 方法会立即释放该线程所持有的所有的锁，导致数据得不到同步，出现数据不一致的问题。
3、使用 interrupt 方法中断线程。
当其他线程调用当前线程的interrupt方法时，即设置了一个标识，表示当前线程可以中断了，至于什么时候中断，取决于当前线程。当前线程通过调用isInterrupted（）方法来判断自身是否被中断，如果返回true,则说明当前线程已经中断，这种通过标识位或中断操作的方式能够使线程在终止时有机会清理资源，而这种方式也更加安全。
suspend()方法 该方法已经遭到反对，因为它具有固有的死锁倾向。调用suspend（）方法的时候，目标线程会停下来。如果目标线程挂起时在保护关键系统资源的监视器上保持有锁，则在目标线程重新开始以前，其他线程都不能访问该资源。除非被挂起的线程恢复运行。对任何其他线程来说，如果想恢复目标线程，同时又试图使用任何一个锁定的资源，就会造成死锁。由于上述原因，因此不应该使用suspend（）和resume()方法，而应在自己的thread类中置入一个标志，用于控制线程是活动还是挂起。如果标志指出线程应该挂起，那么用wait（）方法命令其进入等待状态。如果标志指出线程应当恢复，那么用notify()方法重新启动线程。

线程同步的几种方式
1、synchronized
无论synchronized关键字加在方法上还是对象上，如果它作用的对象是非静态的，则它取得的锁是对象；如果synchronized作用的对象是一个静态方法或一个类，则它取得的锁是对类，该类所有的对象同一把锁。

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。如下：

实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解即可。

而对于顶部，则是Java头对象，它实现synchronized的锁对象的基础，synchronized使用的锁对象是存储在Java对象头里的，jvm中采用2个字来存储对象头(如果对象是数组则会分配3个字，多出来的1个字记录的是数组长度)，其主要结构是由Mark Word 和 Class Metadata Address 组成，其结构说明如下表：

同步代码块
重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSe t集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。
同步方法
方法级的同步是隐式，即无需通过字节码指令来控制的，它实现在方法调用和返回操作之中。JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。当方法调用时，调用指令将会 检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先持有monitor（虚拟机规范中用的是管程一词）， 然后再执行方法，最后再方法完成(无论是正常完成还是非正常完成)时释放monitor。在方法执行期间，执行线程持有了monitor，其他任何线程都无法再获得同一个monitor。如果一个同步方法执行期间抛 出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放。

无论哪种实现，本质上都是对指定对象相关联的monitor的获取，这个过程是互斥性的，也就是说同一时刻只有一个线程能够成功，其它失败的线程会被阻塞，并放入到同步队列中，进入BLOCKED状态。
monitor是线程私有的数据结构，线程一旦进入到被synchronized修饰的方法或代码块时，指定的锁对象通过某些操作将对象头中的LockWord指向monitor 的起始地址与之关联，确保一次只能有一个线程执行该部分的代码。

锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、自旋锁、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。
偏向锁在没有实际竞争的情况下，还能够针对部分场景继续优化。如果不仅仅没有实际竞争，自始至终，使用锁的线程都只有一个，那么，维护轻量级锁都是浪费的。偏向锁的目标是，减少无竞争且只有一个线程使用锁的情况下，使用轻量级锁产生的性能消耗。轻量级锁每次申请、释放锁都至少需要一次CAS，但偏向锁只有初始化时需要一次CAS。
“偏向”的意思是，偏向锁假定将来只有第一个申请锁的线程会使用锁（不会有任何线程再来申请锁），因此，只需要在Mark Word中CAS记录owner（本质上也是更新，但初始值为空），如果记录成功，则偏向锁获取成功，记录锁状态为偏向锁，以后当前线程等于owner就可以零成本的直接获得锁；否则，说明有其他线程竞争，膨胀为轻量级锁。
轻量级锁不需要申请互斥量，仅仅将Mark Word中的部分字节CAS更新指向线程栈中的Lock Record，如果更新成功，则轻量级锁获取成功，记录锁状态为轻量级锁；否则，说明已经有线程获得了轻量级锁，目前发生了锁竞争（不适合继续使用轻量级锁），接下来膨胀为重量级锁。（Mark Word是对象头的一部分；每个线程都拥有自己的线程栈（虚拟机栈），记录线程和函数调用的基本信息。）
当然，由于轻量级锁天然瞄准不存在锁竞争的场景，如果存在锁竞争但不激烈，仍然可以用自旋锁优化，自旋失败后再膨胀为重量级锁。
自旋锁
首先，内核态与用户态的切换上不容易优化。但通过自旋锁，可以减少线程阻塞造成的线程切换（包括挂起线程和恢复线程）。
如果锁的粒度小，那么锁的持有时间比较短（尽管具体的持有时间无法得知，但可以认为，通常有一部分锁能满足上述性质）。那么，对于竞争这些锁的而言，因为锁阻塞造成线程切换的时间与锁持有的时间相当，减少线程阻塞造成的线程切换，能得到较大的性能提升。具体如下：
当前线程竞争锁失败时，打算阻塞自己
不直接阻塞自己，而是自旋（空等待，比如一个空的有限for循环）一会
在自旋的同时重新竞争锁
如果自旋结束前获得了锁，那么锁获取成功；否则，自旋结束后阻塞自己
如果在自旋的时间内，锁就被旧owner释放了，那么当前线程就不需要阻塞自己（也不需要在未来锁释放时恢复），减少了一次线程切换。
这通常发生在锁持有时间长，但竞争不激烈的场景中。

Monitor
Monitor 其实是一种同步工具，或者说是同步机制，在 Monitor Object 模式中，主要有四种类型参与者：
监视者对象 Monitor Object：负责公共的接口方法，这些公共的接口方法会在多线程的环境下被调用执行。
同步方法：这些方法是监视者对象所定义。为了防止竞争条件，无论是否有多个线程并发调用同步方法，还是监视者对象还用多个同步方法，在任一事件内只有一个同步方法能够执行。
监控锁 Monitor Lock：每一个监视者对象都会拥有一把监视锁。
监控条件 Monitor Condition：同步方法使用监视锁和监视条件来决定方法是否需要阻塞或重新执行。

在 Monitor Object 模式中，参与者之间将发生如下协作过程：
同步方法的调用和串行化。当某线程调用监视者对象的同步方法时，必须首先获得它的监视锁。只要监视者对象有其他同步方法正在执行，获取操作便不会成功，该线程将处于阻塞（BLOCKED）状态。当线程获得监控锁后，执行方法实现服务，一旦同步方法完成执行，监视锁自动释放。
同步方法线程挂起。如果调用同步方法的线程必须被阻塞或是其他原因不能立刻进行，它能够在一个监视条件上等待，这将导致该客户线程暂时释放监视锁，并挂起（WAITING / TIMED_WAITING）在监视条件上。
监视条件通知。线程能够通知一个监视条件，目的是为了让一个前期使自己挂起在一个监视条件上的同步方法线程恢复运行。
同步方法线程回复。一旦早先挂起在某监视条件上的同步方法线程获取通知，它将继续在最初的等待监视条件的点上执行，执行的条件是唤醒后抢占到监视锁。

Object 类本身就是监视者对象，Java 对于 Monitor Object 模式做了内建的支持。
每个 Object 都带了一把看不见的锁，通常叫 内部锁/Monitor 锁/Instrinsic Lock, 这把锁就是监控锁，synchronized 关键字修饰方法和代码块就是 同步方法
wait()/notify()/notifyAll() 方法构成监控条件(Monitor Condition)

2、Lock，
如果Synchronized获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。
　因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。
再举个例子：当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。
但是采用synchronized关键字来实现同步的话，就会导致一个问题：
如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程只能等待无法进行读操作。
因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。
另外，通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。

Lock是一个接口：四个方法：lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。
首先lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。
由于在前面讲到如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。
tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。
tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。
lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

ReentrantLock，意思是“可重入锁”，是唯一实现了Lock接口的类

ReadWriteLock：ReadWriteLock也是一个接口，在它里面只定义了两个方法：readLock()和writeLock(),一个用来获取读锁，一个用来获取写锁。也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。ReentrantReadWriteLock实现了ReadWriteLock接口。

选择
如果现有程序已经使用了内置锁，那么尽量保持代码风格统一，尽量不引入Lock，避免两种机制混用，容易令人困惑，也容易发生错误。
Synchronized是JVM的内置属性，他能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果基于类库的锁来实现这些功能，则可能性不大。
ReenTrantLock增加了一些高级功能：①等待可中断；②可实现公平锁；new ReentrantLock(true)会创建出一个公平锁。③可实现选择性通知
lock 必须在 finally 块中释放。否则，如果受保护的代码将抛出异常，锁就有可能永远得不到释放！这一点区别看起来可能没什么，但是实际上，它极为重要。而使用同步，JVM 将确保锁会获得自动释放。
synchronized 代码块不能够保证进入访问等待的线程的先后顺序。 你不能够传递任何参数给一个 synchronized代码块的入口。因此，对于 synchronized 代码块的访问等待设置超时时间是不可能的事情。
synchronized块必须被完整地包含在单个方法里。而一个 Lock 对象可以把它的 lock() 和 unlock() 方法的调用放在不同的方法里。
JDK中的synchronized和JUC中Lock的实现类就是悲观锁，非公平锁，可重入锁，互斥锁（独享锁（共享锁是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据））。

3、volatile
1 . 保证了不同线程对该变量操作的内存可见性;
2 . 禁止指令重排序

int a = 0;
bool flag = false;
public void write() {
    a = 2;              //1
    flag = true;        //2
}
public void multiply() {
    if (flag) {         //3
        int ret = a * a;//4
    } 
}

底层：汇编代码中volatile关键字的代码会多出一个lock前缀指令。
lock前缀指令实际相当于一个内存屏障，内存屏障提供了以下功能：
1 . 重排序时不能把后面的指令重排序到内存屏障之前的位置
2 . 使得本CPU的Cache写入内存
3 . 写入动作也会引起别的CPU或者别的内核无效化其Cache，相当于让新写入的值对别的线程可见。
应用：状态量标记和单例模式的实现

AQS是一个同步器，他的核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态，如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。
CLH（Craig，Landin，and Hagersten）队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例，仅存在节点之间的关联关系。
AQS是将每一条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node），来实现锁的分配。
用大白话来说，AQS就是基于CLH队列，用volatile修饰共享变量state，线程通过CAS去改变状态符，成功则获取锁成功，失败则进入等待队列，等待被唤醒。注意：AQS是自旋锁

CAS虽然很高效，但是它也存在三大问题，这里也简单说一下：

1. ABA问题。CAS需要在操作值的时候检查内存值是否发生变化，没有发生变化才会更新内存值。但是如果内存值原来是A，后来变成了B，然后又变成了A，那么CAS进行检查时会发现值没有发生变化，但是实际上是有变化的。ABA问题的解决思路就是在变量前面添加版本号，每次变量更新的时候都把版本号加一，这样变化过程就从“A－B－A”变成了“1A－2B－3A”。
   JDK从1.5开始提供了AtomicStampedReference类来解决ABA问题，具体操作封装在compareAndSet()中。compareAndSet()首先检查当前引用和当前标志与预期引用和预期标志是否相等，如果都相等，则以原子方式将引用值和标志的值设置为给定的更新值。
2. 循环时间长开销大。CAS操作如果长时间不成功，会导致其一直自旋，给CPU带来非常大的开销。
3. 只能保证一个共享变量的原子操作。对一个共享变量执行操作时，CAS能够保证原子操作，但是对多个共享变量操作时，CAS是无法保证操作的原子性的。

4、ThreadLocal在ThreadLocal类中有一个Map，用于存储每一个线程的变量副本，Map中元素的键为线程对象，而值对应线程的变量副本。

java异常
Java中的异常分为两大类：

1. Checked Exception（非Runtime Exception）
2. Unchecked Exception（Runtime Exception）

Checked Exceptions是我们可以在程序中预期并尝试从中恢复的特殊情况，例如FileNotFoundException。我们应该捕获此异常并向用户提供有用的消息并正确记录以进行调试。Exception是所有Checked Exceptions的父类。
运行时异常是由错误的编程引起的，例如尝试从Array中检索元素。我们应该在尝试检索元素之前先检查数组的长度，否则它可能会ArrayIndexOutOfBoundException在运行时抛出。RuntimeException是所有运行时异常的父类
错误是超出应用程序范围的特殊情况，并且无法预测并从中恢复，例如硬件故障，JVM崩溃或内存不足错误。

常见异常：

1. java.lang.ArithmeticException 算术运算异常,因为除数为0，所以引发了算数异常
2. java.lang.StringIndexOutOfBoundsException: 截取字符串substring()产生的下标越界异常。原因是可能是字符串为空，或长度不足1
3. java.lang.NullPointerException 空指针异常
4. ClassCastException 类型强制转换异常
5. IllegalArgumentException 传递非法参数异常
6. ClientAbortException: java.io.IOException异常 原因是由于服务器正在处理http请求，正在输出内容时，用户关闭了浏览器，造成了ClientAbortException异常。它属于I/O异常中比较常见的一种。
7. ClientAbortException Caused by: java.net.SocketException: Connection reset by peer: socket write error 服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉，或者客户关掉了浏览器，而服务器还在给客户端发送数据

如果try中没有异常，则顺序为try→finally，如果try中有异常，则顺序为try→catch→finally；
当try和catch中带有return时，会先执行return前的代码，然后暂时保存需要return的信息，再执行finally中的代码，最后再通过return返回之前保存的信息。
当finally中有return的时候，try中的return会失效，在执行完finally的return之后，就不会再执行try中的return。这种写法编译器会给予警告，一旦finally里出现异常，会导致catch中的异常被覆盖。

Throw：作用在方法内，表示抛出具体异常，由方法体内的语句处理。
具体向外抛出的动作，所以它抛出的是一个异常实体类。若执行了Throw一定是抛出了某种异常。
Throws：作用在方法的声明上，表示如果抛出异常，则由该方法的调用者来进行异常处理。
主要的声明这个方法会抛出会抛出某种类型的异常，让它的使用者知道捕获异常的类型。
出现异常是一种可能性，但不一定会发生异常。

final关键字可以与类变量一起使用，以便它们不能被重新分配，类可以避免按类扩展，并且使用方法来避免子类覆盖。
finally关键字与try-catch块一起使用，以提供始终执行的语句即使出现一些异常，通常最终也会用来关闭资源。
finalize（）方法由垃圾收集器在销毁对象之前执行，这是确保关闭所有全局资源的好方法。

java内存管理

1.类加载器（ClassLoader）:在JVM启动时或者在类运行时将需要的class加载到JVM中。

2.执行引擎：负责执行class文件中包含的字节码指令（执行引擎的工作机制，这里也不细说了，这里主要介绍JVM结构）；

3.内存区（也叫运行时数据区）：是在JVM运行的时候操作所分配的内存区。运行时内存区主要可以划分为5个区域:

1. 方法区(Method Area)：用于存储类结构信息的地方：常量池、静态变量、构造函数等，常量池包括static final修饰的成员变量、八种基本数据类型的静态变量会在方法区开辟空间，引用类型的静态变量如果未用new关键字为引用类型的静态变量分配对象（如：static Object obj;）那么对象的引用obj会存储在方法区中，并为其指定默认值null;若，对于引用类型的静态变量如果用new关键字为引用类型的静态变量分配对象（如：static Person person = new Person();）,那么对象的引用person 会存储在方法区中，并且该对象在堆中的地址也会存储在方法区中（注意此时静态变量只存储了对象的堆地址，而对象本身仍在堆内存中）。
2. java堆(Heap)：存储java实例或者对象的地方。这块是GC的主要区域。方法区和堆是被所有java线程共享的。
3. java栈(Stack)：java栈总是和线程关联在一起，每当创建一个线程时，JVM就会为这个线程创建一个对应的java栈。在这个java栈中又会包含多个栈帧，每运行一个方法就创建一个栈帧，用于存储局部变量表、操作栈、方法返回值等。每一个方法从调用直至执行完成的过程，就对应一个栈帧在java栈中入栈到出栈的过程。所以java栈是现成私有的。
4. 程序计数器(PC Register)：用于保存当前线程执行的内存地址。由于JVM程序是多线程执行的（线程轮流切换），所以为了保证线程切换回来后，还能恢复到原先状态，就需要一个独立的计数器，记录之前中断的地方，可见程序计数器也是线程私有的。
5. 本地方法栈(Native Method Stack)：和java栈的作用差不多，只不过是为JVM使用到的native方法服务的。

双亲委派模型

在类加载时，系统会判断当前类是否已经加载，如果已经加载了，就直接返回可用的类，否则就会尝试去加载这个类。在尝试加载类时，会先委派给其父加载器加载，最终传到顶层的加载器加载。如果父类加载器在自己的负责的范围内没有找到这个类，就会下推给子类加载器加载。

双亲委派模型
双亲委派模型
可见检查类是否加载的委派过程是单向的，底层的类加载器询问了半天，到最后还是自己加载类，那不白费力气了吗？这样做当然有它的好的，这样在结构上比较清晰，最重要的是可以避免多层级的加载器重复加载某些类

双亲委派模型的弊端

双亲委派模型检查类加载是单向的，但这样也有个弊端就是上层的类加载器无法访问由下层类加载器所加载的类。那如果启动类加载器加载的系统类中提供了一个接口，接口需要在应用中实现，还绑定了一个工厂方法，用于创建该接口的实例。而接口和工厂方法都在启动类加载器中。这时就会出现该工厂无法创建由应用类加载器加载的应用实例的问题。比如 JDBC、XML Parser 等

jvm 这么厉害，肯定会有办法解决这种问题的，没错，java 中通过 SPI（Service Provider Interface）机制解来解决这类问题

Java的内存分配原理
与C/C++不同，C/C++每次申请内存时都要malloc进行系统调用，而系统调用发生在内核空间，每次都要中断进行切换，这需要一定的开销，而Java虚拟机是先一次性分配一块较大的空间，然后每次new时都在该空间上进行分配和释放，减少了系统调用的次数，节省了一定的开销，这有点类似于内存池的概念；如何进行分配和回收就跟GC机制有关了。

年轻代：是所有新对象产生的地方。年轻代被分为3个部分——Enden区和两个Survivor区，当Eden区被对象填满时，就会执行Minor GC。并把所有存活下来的对象转移到其中一个survivor区。Minor GC同样会检查存活下来的对象，并把它们转移到另一个survivor区。这样在一段时间内，总会有一个空的survivor区。经过多次GC周期后，仍然存活下来的对象会被转移到年老代内存空间。通常是通过设定年龄阈值来完成的，例如15次。

年老代：在年轻代中经历了N次回收后仍然没有被清除的对象，就会被放到年老代中，都是生命周期较长的对象。对于年老代和永久代，就不能再采用像年轻代中那样搬移腾挪的回收算法，因为那些对于这些回收战场上的老兵来说是小儿科。通常会在老年代内存被占满时将会触发Full GC,回收整个堆内存（比较大的会直接放在年老代）。

持久代：类信息和静态变量。持久代对垃圾回收没有显著的影响。
元空间导致的变化：

1. 之前不管是不是需要，JVM都会吃掉那块空间，如果设置得太小，JVM会死掉；如果设置得太大，这块内存就被JVM浪费了。理论上说，现在你完全可以不关注这个，因为JVM会在运行时自动调校为“合适的大小”；
2. 提高Full GC的性能，在Full GC期间，Metadata到Metadata pointers之间不需要扫描了，别小看这几纳秒时间；
3. 隐患就是如果程序存在内存泄露，像OOMTest那样，不停的扩展metaspace的空间，会导致机器的内存不足，所以还是要有必要的调试和监控。

方法区可以选择是否执行垃圾收集。同时满足下面三个条件的类，才可以被回收，但是仅仅是可以，并非不使用了必然会回收，受虚拟机参数控制。

1. 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
2. 加载类的ClassLoader已经被回收。
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过发射访问该类的方法。

引用计数（已淘汰）
可达性分析法（根搜索算法）
有一系列“GCRoots”起点，从这些点开始向下搜索，走过的路径称为“引用链”。若一个对象没有任何引用链可到达GC Roots，那么该对象就是不可用的，即使该对象还与其他对象相关联。
经可达性分析算法所标记出的对象，会再进行一次筛选（根据是否重写finalize方法）。若经过筛选，判定可回收，那么就会立即回收；若判定没有必要回收，那么就将对象放入F-Queue队列中，进行二次筛查。JVM会创建一个低优先级的Finalize线程来执行这个方法，这里强调低优先级和执行，是指JVM会触发这个方法，但不提供等待执行完成的保证。这是出于安全的考虑，因为执行finalize时，可能非常缓慢，甚至发生死循环，而队列可能还有人等着判刑呢，不能让他们等太久。二次筛查会执行对象的finalize()方法。若对象在这个过程重新与引用链上的任何一个对象建立关联，那么该对象就会从回收集合中移除。否则，对象会被回收。

GC Root的对象主要有以下几种：
虚拟机栈(栈帧中的本地变量表)中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中native方法引用的对象。

1、强引用是指创建一个对象并把这个对象赋给一个引用变量。 强引用有引用变量指向时永远不会被垃圾回收，JVM宁愿抛出OutOfMemory错误也不会回收这种对象。如果想中断强引用和某个对象之间的关联，可以显示地将引用赋值为null，这样一来的话，JVM在合适的时间就会回收该对象。
2、软引用（SoftReference）如果一个对象具有软引用，内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
3、弱引用也是用来描述非必需对象的，当JVM进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。在java中，用java.lang.ref.WeakReference类来表示。
4、虚引用和前面的软引用、弱引用不同，它并不影响对象的生命周期。在java中用java.lang.ref.PhantomReference类表示。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。要注意的是，虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之 关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

避免避免full gc
1.对象不用时最好显示置为NULL
一般而言，为NULL的对象都会被作为垃圾处理，所以将不用的对象置为NULL，有利于GC收集器判定垃圾，从而提高了GC的效率。
2.尽量少使用System,gc()
此函数建议JVM进行主GC，会增加主GC的频率，增加了间接性停顿的次数。
3.尽量少使用静态变量
静态变量属于全局变量，不会被GC回收，他们会一直占用内存
4.尽量使用StringBuffer,而不使用String来累加字符串
5.分散对象创建或删除的时间
集中在短时间内大量创建新对象，特别是大对象，会导致突然需要大量内存，JVM在这种情况下只能进行主GC以回收内存，从而增加主GC的频率。
6.尽量少用finaliza函数
它会加大GC的工作量。
7.如果有需要使用经常用到的图片，可以使用软引用类型，将图片保存在内存中，而不引起outofmemory
8.能用基本类型入INT就不用对象Integer
9.增大-Xmx的值

Stop The World
当虚拟机完成两次标记后，便确认了可以回收的对象。但是，垃圾回收并不会阻塞我们程序的线程，他是与当前程序并发执行的。所以问题就出在这里，当GC线程标记好了一个对象的时候，此时我们程序的线程又将该对象重新加入了“关系网”中，当执行二次标记的时候，该对象也没有重写finalize()方法，因此回收的时候就会回收这个不该回收的对象。
解决方法就是在一些特定指令位置设置一些“安全点”，当程序运行到这些“安全点”的时候就会暂停所有当前运行的线程（Stop The World 所以叫STW），暂停后再找到“GC Roots”进行关系的组建，进而执行标记和清除。
这些特定的指令位置主要在：
1、循环的末尾
2、方法临返回前 / 调用方法的call指令后
3、可能抛异常的位置

java流
字节流一般用来处理图像，视频，以及PPT，Word类型的文件。字符流一般用于处理纯文本类型的文件，如TXT文件等，字节流可以用来处理纯文本文件，但是字符流不能用于处理图像视频等非文本类型的文件。
节流没有缓冲区，是直接输出的，而字符流是输出到缓冲区的。因此在输出时，字节流不调用colse()方法时，信息已经输出了，而字符流只有在调用close()方法关闭缓冲区时，信息才输出。要想字符流在未关闭时输出信息，则需要手动调用flush()方法。

jsp和servlet
jsp就是在html里面写java代码，servlet就是在java里面写html代码…其实jsp经过容器解释之后就是servlet.只是我们自己写代码的时候尽量能让它们各司其职，jsp更注重前端显示，servlet更注重模型和业务逻辑。不要写出万能的jsp或servlet来即可。
Servlet是一个遵循Servlet开发的java类。
JSP本身就是一种Servlet。它在第一次被访问的时候会被编译为HttpJspPage类。

过滤器可以简单的理解为“取你所想取”，过滤器关注的是web请求；
拦截器可以简单的理解为“拒你所想拒”，拦截器关注的是方法调用，比如拦截敏感词汇。拦截器是基于java反射机制来实现的，而过滤器是基于函数回调来实现的。我们如果在项目中使用了Spring框架，那么，我们可以直接继承HandlerInterceptorAdapter这个抽象类，来实现我们自己的拦截器。

jdk1.8变化
1、default关键字
在java里面，我们通常都是认为接口里面是只能有抽象方法，不能有任何方法的实现的，那么在jdk1.8里面打破了这个规定，引入了新的关键字default，通过使用default修饰方法，可以让我们在接口里面定义具体的方法实现。
2、Lambda 表达式
Lambda表达式是jdk1.8里面的一个重要的更新，这意味着java也开始承认了函数式编程，也就是说函数既可以作为参数，也可以作为返回值。
3、流
它允许我们以声明性方式处理数据集合(通过查询语句来表达，而不是临时编写一个实现)。就现在来说，我们可以把它们看成遍历数据集的高级迭代器。此外，流还可以透明地并行处理，也就是说我们不用写多线程代码了。
4、Date Api更新
5、把存放元数据中的永久内存从堆内存中移到了本地内存（物理内存，非虚拟机）中，永久内存不再占用堆内存，它可以通过自动增长来避免JDK7以及前期版本中常见的永久内存错误(java.lang.OutOfMemoryError: PermGen)，可以通过参数可以设置Matespace内存大小，可以避免过度浪费本地内存，但有内存泄漏的问题。Metaspace 垃圾回收
对于僵死的类及类加载器的垃圾回收将在元数据使用达到“MaxMetaspaceSize”参数的设定值时进行。适时地监控和调整元空间对于减小垃圾回收频率和减少延时是很有必要的。持续的元空间垃圾回收说明，可能存在类、类加载器导致的内存泄漏或是大小设置不合适。
更新原因
1、字符串存在永久代中，容易出现性能问题和内存溢出。
2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代(就小了）溢出。
3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

其他

单例模式
实用场景：配置文件、线程池、Runtime（饿汉）：描述了虚拟机一些信息（内存大小等）
1、懒汉式

懒汉式，顾名思义就是实例在用到的时候才去创建，“比较懒”，用的时候才去检查有没有实例，如果有则返回，没有则新建。有线程安全和线程不安全两种写法，区别就是synchronized关键字。

2、饿汉式

饿汉式，从名字上也很好理解，就是“比较勤”，实例在初始化的时候就已经建好了，不管你有没有用到，都先建好了再说。好处是没有线程安全的问题，坏处是浪费内存空间。

3、双检锁

双检锁，又叫双重校验锁，综合了懒汉式和饿汉式两者的优缺点整合而成。看上面代码实现中，特点是在synchronized关键字内外都加了一层 if 条件判断，这样既保证了线程安全，又比直接上锁提高了执行效率，还节省了内存空间。

4、静态内部类

静态内部类的方式效果类似双检锁，但实现更简单。但这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。

设计模式
代理：spring
代理类与委托类有同样的接口，代理类主要负责为委托类预处理消息、过滤消息、把消息转发给委托类，以及事后处理消息等。代理类与委托类之间通常会存在关联关系，一个代理类的对象与一个委托类的对象关联，代理类的对象本身并不真正实现服务，而是通过调用委托类的对象的相关方法，来提供特定的服务。简单的说就是，我们在访问实际对象时，是通过代理对象来访问的，代理模式就是在访问实际对象时引入一定程度的间接性，因为这种间接性，可以附加多种用途。

装饰模式，允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。这种模式创建了一个装饰类，用来包装原有的类，提供了额外的功能。在不想增加很多子类的情况下扩展类时。装饰类和被装饰类可以独立发展，而不会相互耦合。它有效地把类的核心职责和装饰功能分开了。装饰模式是继承关系的一个替代方案。装饰模式可以动态地扩展一个实现类的功能。
装饰模式比继承要灵活。避免了继承体系臃肿。而且降低了类于类之间的关系。

装饰模式和代理模式就行为目的而言，二者是相反的（装饰模式：增强，代理模式：限制）
装饰器模式：能动态的新增或组合对象的行为。
代理模式：为其他对象提供一种代理以控制对这个对象的访问.（换句话说，可以不执行某功能）
装饰模式是“新增行为”，而代理模式是“控制访问”。
装饰模式是在原有基础之上增加额外的功能，而代理模式有两种情况可以使用第一种是延迟代理对象，对于大文件或者目前还未加载完的对象，使用比较合适。第二种为权限判断，在调用功能前判断当前用户是否有此权限。
装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案；
代理模式给一个对象提供一个代理对象，并有代理对象来控制对原有对象的引用；

装饰模式和继承的区别

SqlSessionFactory（工厂接口）：依靠它来生成 SqlSession，使用的是工厂模式。
工厂模式是属于创建型模式，它提供了一种创建对象的最佳方式。避免了子类与父类接口的耦合关系，当接口有多个子类时，可以消除更换子类对主方法的影响。

观察者模式
观察者模式（又被称为发布-订阅（Publish/Subscribe）模式，属于行为型模式的一种，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。

观察者模式结构图

在观察者模式中有如下角色：
Subject：抽象主题（抽象被观察者），抽象主题角色把所有观察者对象保存在一个集合里，每个主题都可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察者对象。
ConcreteSubject：具体主题（具体被观察者），该角色将有关状态存入具体观察者对象，在具体主题的内部状态发生改变时，给所有注册过的观察者发送通知。
Observer：抽象观察者，是观察者者的抽象类，它定义了一个更新接口，使得在得到主题更改通知时更新自己。
ConcrereObserver：具体观察者，实现抽象观察者定义的更新接口，以便在得到主题更改通知时更新自身的状态。

适配器模式把一个类接口变化成客户端所期待的另一个类的接口，使原来因接口不匹配而无法一起工作的类能够一起工作。

1.用UUID生成十六位数唯一订单号
2.也可以时间+随机数
3.高并发性下，确保订单的唯一性，可以把用户id加进去
4.雪花算法
UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。
snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)
snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。据说：snowflake每秒能够产生26万个ID。

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储技术、内容分发技术和负载均衡技术。

nginx是一个web服务器，反向代理服务器，缓存服务器
Nginx负载均衡算法
1、轮询（默认）每个请求按时间顺序逐一分配到不同的后端服务，如果后端某台服务器死机，自动剔除故障系统，使用户访问不受影响。
2、weight（轮询权值）weight的值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下。或者仅仅为在主从的情况下设置不同的权值，达到合理有效的地利用主机资源。
3、ip_hash源地址哈希法源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，推荐协议为dubbo://
Dubbo服务之间的调用默认是同步等待结果阻塞的，支持异步调用。

1、单一应用架构：当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
2、垂直应用架构：当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
3、分布式服务架构：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
4、流动计算架构：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

要有 RPC，HTTP 不好么？
因为 RPC 和 HTTP 就不是一个层级的东西，所以严格意义上这两个没有可比性，也不应该来作比较，而题目问的就是把这两个作为比较了。
HTTP 只是传输协议，协议只是规范了一定的交流格式，而且 RPC 是早于 HTTP 的，所以真要问也是问有 RPC 为什么还要 HTTP。
RPC 对比的是本地过程调用，是用来作为分布式系统之间的通信，它可以用 HTTP 来传输，也可以基于 TCP 自定义协议传输。
可以说 HTTP 协议比较冗余，所以 RPC 大多都是基于 TCP 自定义协议，定制化的才是最适合自己的。
当然也有基于 HTTP 协议的 RPC 框架，毕竟 HTTP 是公开的协议，比较通用，像 HTTP2 已经做了相应的压缩了，而且系统之间的调用都在内网，所以说影响也不会很大。

Consumer 需要调用远程服务的服务消费方
Registry 注册中心
Provider 服务提供方
Container 服务运行的容器
Monitor 监控中心
首先服务提供者 Provider 启动然后向注册中心注册自己所能提供的服务。
服务消费者 Consumer 启动向注册中心订阅自己所需的服务。然后注册中心将提供者元信息通知给 Consumer， 之后 Consumer 因为已经从注册中心获取提供者的地址，因此可以通过负载均衡选择一个 Provider 直接调用 。
之后服务提供方元数据变更的话注册中心会把变更推送给服务消费者。
服务提供者和消费者都会在内存中记录着调用的次数和时间，然后定时的发送统计数据到监控中心。

秒杀
限流：按钮禁灰、答题验证码、cdn
削峰：MQ 中间件来解决
异步：通过redis异步的方式来处理订单，提升秒杀的效率，降低无意义的线程等待
缓存：热点数据

android相关

ios相关
KVC:是一种可以直接通过字符串的名字（key）来访问类属性的机制，而不是通过调用的Setter、Getter方法访问。KVC的实现细节：搜索Setter、Getter方法
Key-Value-Observing–KVO(键值观察者模式)
此机制可以在一个类中监听另外一个类的属性变化，包括我们自己的类和已有的Cocoa类库中的类。当被监听的类的属性发生了变化时，观察者会收到通知，可以针对属性变化添加自己的动作。

智力
智力2

职业规划
1-3：了解公司业务，加强技术学习，明确后期想要深入的技术方向，从向monter学习到cover monter，比如请假，可以自己cover他的任务，；
3-5：有了之前的技术学习，应从学习中转入实践，检查弱点，提升优点，有能力指导应届生，帮助组内提高业绩；
5：新的高度，项目的整体架构和管理；