目录

1.Java运算符优先级... 9

2.HTML，JS，CSS的区别... 10

1、HTML—Hypertext Markup Language. 10

2、CSS—Cascading Style Sheet 10

3、JavaScript 10

3.从输入URL到网页呈现的过程... 10

TCP/IP请求... 11

三次握手的步骤：（抽象派）... 11

为何不是二次握手，四次握手？... 11

四次挥手的步骤：（抽象派）... 12

4.五层协议：... 12

5.HTTP长连接和短连接原理浅析... 13

1. HTTP协议与TCP/IP协议的关系... 13

2. 如何理解HTTP协议是无状态的... 13

3. 什么是长连接、短连接？... 13

3.1 TCP连接... 13

3.2 TCP短连接... 14

3.3 TCP长连接... 15

3.4 长连接短连接操作过程... 15

4. 长连接和短连接的优点和缺点... 15

5. 什么时候用长连接，短连接？... 15

6.Java中List几种去重方式的比较... 16

7.乐观锁和悲观锁... 16

一、概念... 16

二、两种锁的使用场景... 16

三、乐观锁的实现方式... 16

四、乐观锁的缺点... 16

五、CAS与synchronized的使用情景... 17

8.HashMap底层实现原理 扩容机制... 17

实现原理：... 17

扩容机制：... 18

Hashmap为什么大小是2的幂次？... 19

get方法实现... 20

9.运算符... 20

1.十进制转二进制... 20

2.二进制转十进制... 21

3.位异或运算（^）... 21

4.位与运算符（&）... 21

5.位或运算符（|）... 21

6.位非运算符（~）... 21

10.ConcurrentHashMap,put值时key和value都不能为空... 22

11.Java-五种线程池，四种拒绝策略，三种阻塞队列... 22

三种阻塞队列：... 22

四种拒绝策略：... 23

五种线程池：... 23

12.Map、Set、List是否有序... 23

HashSet：... 24

LinkedHashSet：... 24

13.重写对象的equals()方法... 26

14.Redis的持久化(Rdb. Aof) 26

RDB 方式与 AOF 方式的优势对比... 26

RDB 方式的优点... 26

AOF 方式的优点... 26

优点对比总结... 27

RDB 方式与 AOF 方式的缺点对比... 27

RDB 方式的缺点... 27

AOF 方式的缺点... 27

缺点对比总结... 27

15.Redis事务使用方法 watch和unwatch. 28

16.主从复制原理（配从不配主slaveof 主机IP 主机端口）... 28

redis主从复制可以根据是否是全量分为全量同步和增量同步... 28

17.哨兵机制... 28

18.缓存穿透及优化... 29

问题解决：... 29

19.缓存击穿及优化... 29

解决：... 29

20.MYSQL. 29

UNION.. 29

索引(where的查找速度orderby的排序) 30

优点... 30

缺点... 30

有利于建索引的条件... 30

不利于建索引的情况... 30

操作实例... 31

21.java 字符流与字节流哪个快... 31

22.http与https连接建立... 31

建立连接... 31

tcp的三次挥手和四次挥手... 31

HTTP请求过程... 32

HTTPS. 33

23.数据库四大特性和事务隔离级别... 33

1、事务的隔离级别... 33

（1）Read uncommitted(未授权读取、读未提交)：... 34

（2）Read committed（授权读取、读提交）：... 34

（3）Repeatable read（可重复读取）：... 34

（4）Serializable（序列化）：... 34

2、出现的问题：... 34

（1）脏读... 35

（2）不可重复读... 35

（3）虚读(幻读) 36

3、MySQL数据库提供的四种隔离级别：... 36

4、事务的四大特性... 38

（1）原子性（Atomicity）... 38

（2）一致性（Consistency）... 38

（3）隔离性（Isolation）... 38

（4）持久性（Durability）... 38

24.处理高并发的六种方法... 39

25. 高并发的解决方案... 39

1.应用和静态资源分离... 39

2.页面缓存... 40

3.集群与分布式... 40

4. 反向代理... 41

4.1 反向代理服务器和代理服务器的区别... 42

4.2反向代理服务器主要有三个作用：... 42

5. CDN.. 42

6. 底层的优化... 43

7.数据库集群和库表散列... 43

8. 小结... 43

其它简单总结：... 43

高并发的解决方案... 44

海量数据的解决方案... 45

1 使用缓存... 45

2 页面静态化---不想解释，还有什么值得去解释呢？... 45

3 数据库优化... 45

4 分离数据库中的活跃数据... 45

5 读写分离... 45

26.数据库读写分离，主从同步复制实现方法... 45

实现思路... 45

基础知识... 46

主从同步复制有以下几种方式：... 46

主从数据库设置的具体步骤... 46

1.打开mysql数据库配置文件... 47

2.在主服务器master上配置开启Binary log，主要是在[mysqld]下面添加：... 47

3.重启mysql服务... 47

4.检查配置效果，进入主数据库并执行... 47

5.配置从服务器的 my.cnf 47

6.接下来配置两个数据库的关联... 48

27. 如何保证缓存与数据库的双写一致性？... 49

最初级的缓存不一致问题及解决方案... 49

28. 同步和异步，阻塞和非阻塞... 49

29. 在UTF-8中，一个汉字为什么需要三个字节？... 50

30.逃逸分析... 51

31. 进程间通信机制有哪些？... 52

32.TCP和UDP的区别和优缺点... 53

1、TCP与UDP区别总结：... 53

2、为什么UDP有时比TCP更有优势?. 54

33. HTTP状态码... 54

消息... 54

100 Continue. 54

101 Switching Protocols. 54

102 Processing.. 54

成功... 54

200 OK.. 55

201 Created.. 55

202 Accepted.. 55

203 Non-Authoritative Information.. 55

204 No Content. 55

205 Reset Content. 55

206 Partial Content. 55

207 Multi-Status. 56

重定向... 56

300 Multiple Choices. 56

301 Moved Permanently. 56

302 Move Temporarily. 56

303 See Other. 57

304 Not Modified.. 57

305 Use Proxy. 57

306 Switch Proxy. 57

307 Temporary Redirect 57

请求错误... 58

400 Bad Request. 58

401 Unauthorized.. 58

402 Payment Required.. 58

403 Forbidden.. 58

404 Not Found.. 58

405 Method Not Allowed.. 58

406 Not Acceptable. 58

407 Proxy Authentication Required.. 59

408 Request Timeout. 59

409 Conflict. 59

410 Gone. 59

411 Length Required.. 59

412 Precondition Failed.. 59

413 Request Entity Too Large. 59

414 Request-URI Too Long.. 59

415 Unsupported Media Type. 60

416 Requested Range Not Satisfiable. 60

417 Expectation Failed.. 60

418 I'm a teapot. 60

421 Too Many Connections. 60

422 Unprocessable Entity. 60

423 Locked.. 60

424 Failed Dependency. 60

425 Too Early. 60

426 Upgrade Required.. 60

449 Retry With.. 60

451 Unavailable For Legal Reasons. 61

服务器错误... 61

500 Internal Server Error. 61

501 Not Implemented.. 61

502 Bad Gateway. 61

503 Service Unavailable. 61

504 Gateway Timeout. 61

505 HTTP Version Not Supported.. 61

506 Variant Also Negotiates. 61

507 Insufficient Storage. 61

509 Bandwidth Limit Exceeded.. 62

510 Not Extended.. 62

600 Unparseable Response Headers. 62

34.DNS原理及其解析过程... 62

DNS 的过程？... 62

Dns服务的工作过程... 62

解析顺序... 64

35. HTTP请求报文（请求行、请求头、请求体）... 64

1.简介... 64

2.特点... 64

3.HTTP请求报文... 65

请求行：... 65

请求头：... 65

请求体：... 65

Accept 65

Accept:text/plain. 66

cookie. 66

Referer 66

Cache-Control 66

4.HTTP响应报文... 66

响应行：... 67

响应头：... 67

响应体：... 67

响应状态码... 67

常见的HTTP响应报文头属性... 68

ETag. 68

Location. 68

5.cookie机制：... 68

36. MySQL索引查询失效的几个情况：... 69

首先，复习一下索引的创建：... 69

索引查询失效的几个情况：... 69

37.Mysql 锁类型和加锁分析... 70

一、锁类型介绍：... 70

二、死锁产生原因和示例... 70

1、产生原因：... 70

2、产生示例：... 71

此类死锁，产生的几个前提：... 78

38. 进程所占的虚拟内存和物理内存是什么样的... 78

扩展资料... 79

39.jvm进程所占用的虚存大于了虚拟机的堆栈设置参数，为什么不报错... 79

40. Mysql怎么保证一致性的？... 80

41.Mysql怎么保证原子性的？... 81

42. Mysql怎么保证持久性的？... 81

43. Mysql怎么保证隔离性的？... 82

44. Mysql中的MVCC策略... 84

什么是MVCC?. 84

特点... 84

基本原理... 85

基本特征... 85

InnoDB存储引擎MVCC的实现策略... 85

MVCC下InnoDB的增删查改是怎么work的... 85

关于Mysql中MVCC的总结... 87

45.mysql分表的3种方法... 88

一，先说一下为什么要分表... 88

二，分表... 88

1，做mysql集群，... 88

2，预先估计会出现大数据量并且访问频繁的表，将其分为若干个表... 89

3，利用merge存储引擎来实现分表... 90

三，总结一下... 92

46. Mysql分表和分区的区别、分库分表介绍与区别... 93

分表与分区：... 93

一,什么是mysql分表，分区... 93

二, mysql分表和分区有什么区别呢... 93

1.实现方式上... 93

3.提高性能上... 94

三，mysql分表和分区有什么联系呢... 94

分库与分表：... 95

1 基本思想之什么是分库分表？... 95

2 基本思想之为什么要分库分表？... 95

3 分库分表的实施策略。... 95

4 分库分表存在的问题。... 97

47. session，cookie和token究竟是什么... 98

http是一个无状态协议... 98

cookie和session. 98

注意... 98

小结... 99

token. 99

组成... 99

存放... 99

token认证流程... 99

token可以抵抗csrf，cookie+session不行... 99

分布式情况下的session和token. 100

总结... 100

48. token 防止csrf 100

验证 HTTP Referer 字段... 100

在请求地址中添加 token 并验证... 101

在 HTTP 头中自定义属性并验证... 102

49. 内存泄漏和内存溢出的区别和联系... 103

1、内存泄漏memory leak : 103

2、内存溢出 out of memory : 103

3、二者的关系... 103

4、内存泄漏的分类（按发生方式来分类）... 104

5、内存溢出的原因及解决方法：... 104

内存溢出原因：... 104

内存溢出的解决方案：... 105

6.Java内存泄露引起原因... 105

1、静态集合类引起内存泄露(static 对象是不会被GC回收的)：... 106

2、当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。... 106

3、各种连接... 107

4、单例模式... 107

5、读取流没有关闭... 108

6、监听器... 108

7、String的intern方法... 108

8、 将没有实现hashCode()和equals()方法的对象加入到HashSet中... 108

7. 查找内存泄漏的方法... 109

3.1 记录gc日志... 109

3.2 进行profiling. 109

3.3 代码审查... 109

50.到底什么是hash呢?hash碰撞？为什么HashMap的初始容量是16？... 109

一 、到底什么是hash呢?. 109

预备小知识：... 109

二，什么是hash碰撞... 111

三、碰撞处理... 111

(1)开放寻址法... 112

（2）链接法... 114

四，为什么HashMap初始容量是2<<3?. 115

51. 线程及与进程的对比... 116

一、为什么要引入线程... 116

二、线程... 117

1、线程的基本概念... 117

2、引入线程的好处... 117

3、线程的适用范围... 117

4、线程分类与执行... 118

三、进程与线程... 119

1、进程和线程的关系... 119

2、线程与进程的区别... 119

3、线程与进程对比... 119

52. Java基本数据类型及所占字节大小... 121

一、Java基本数据类型... 121

二、各数据类型所占字节大小... 121

53. MySQL有哪几种join方式，底层原理是什么？... 122

1.Java运算符优先级

2.HTML，JS，CSS的区别

1、HTML—Hypertext Markup Language

超文本标记语言。它通过标记符号来标记要显示的网页中的各个部分。网页文件本身是一种文本文件，通过在文本文件中添加标记符，可以告诉浏览器如何显示其中的内容（比如文字如何处理，画面如何安排，图片如何显示等）。浏览器按顺序阅读网页文件，然后根据标记符解释和显示其标记的内容：

<html> <head> <title>HTML</title> </head> <body> </body> </html>

HTML文本中包含了所谓的“链接点”HTML利用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本。总的来说，HTML就是整合网页结构和内容显示的一种语言。

2、CSS—Cascading Style Sheet

层叠样式表单。是将样式信息与网页内容分离的一种标记语言。我们在牛腩新闻发布系统中，我们使用过CSS文件，对一些标签的样式进行修改。

3、JavaScript

Javascript是一种基于对象(Object)和事件驱动(Event Driven)并具有安全性能的脚本语言。使用它的目的是与HTML超文本标记语言、Java脚本语言(Java小程序)一起实现在一个Web页面中链接多个对象，与Web客户交互作用。例如可以设置鼠标悬停效果，在客户端验证表单，创建定制的HTML页面，显示警告框，设置cookie等等。

3.从输入URL到网页呈现的过程

开启网络线程到发出一个完整的http请求

到这步，浏览器就要开始发送请求了，但是在发送请求之前，需要进行诸如dns解析，tcp/ip建立链接，五层因特网协议栈之类的操作。

首先，第一步就是进行dns解析。

此处依次分为如下几步：

检查浏览器DNS缓存

检查本地DNS缓存

检查HOST文件

向DNS域名服务器查询

DNS查询用的是UDP协议，DNS协议工作在应用层，使用53号端口，UDP协议工作在传输层

TCP/IP请求

http的本质就是tcp/ip请求

首先TCP协议有以下特点：

面向连接，可靠传输（无差错，不丢失，不重复且有序）

每个TCP连接只能有两个端点，即点对点，一对一连接

TCP提供全双工通信，所以TCP连接的两端都有缓存

发送方缓存存储：1.需要发送但还未发送的数据 2.已发送，但还未收到确认的数据

接收方缓存存储：1.按序到达，但未被应用程序读取的数据 2.未按序到达的数据

工作在传输层（传输层的作用是负责应用程序之间的通信，是端到端的通信，这也是为什么TCP报文首部固定字段【20字节】中最先存的就是源端口号和目的端口号）

需要了解3次握手规则建立连接以及断开连接时的四次挥手

tcp将http长报文划分为短报文，通过三次握手与服务端建立连接，进行可靠传输

三次握手的步骤：（抽象派）

客户端：喂，你听得到吗？

服务端：我听得到呀，你听得到我吗？

客户端：我能听到你，今天balabala……

从这个连接建立的过程，有以下几点知识点：

客户机向服务器发送一个连接请求，这时要将SYN（为1表示该报文为连接请求或者连接接收报文）标识为1，同时随机选择一个起始序列号seq = x

不能携带数据，但要消耗一个序号

服务器接收到连接请求后，返回确认报文，设置SYN = 1，ACK = 1，seq = y（随机设置），ack = x + 1（表示x已收到，期待x + 1的到来），表示确认。

SYN = 1， ACK = 0 表示连接请求报文，SYN = 1，ACK = 1 表示连接接收报文

SYN = 1时，报文段不能有数据部分，而且要消耗一个序号

seq为序号字段，表示本报文数据的第一个字节的序号，不过三次握手前两次中，是不允许带数据的

ack为确认号，表示期望收到对方下一个报文的数据的第一个字节的序号，也就是前面的数据都收到了

这步时，服务器已经开始给连接分配缓存和变量了，而客户机是在第三步才分配，所以服务器易收到SYN洪泛攻击

客户机收到服务器的连接接收报文，还要向服务器给出确认，并且也要给连接分配缓存和变量。此时返回ACK = 1，seq = x + 1，ack = y + 1，此时可以携带数据

客户机是在第三次握手时才分配连接缓存和变量

由于此时不用将SYN设置为1，所以报文可以携带数据

如果不携带数据，则不用消耗序号

之后就可以愉快的传输数据了，记得ACK得一直设为1

为何不是二次握手，四次握手？

简单来说不是二次握手是这样：

1：A发，B收， B知道A能发

2：B发，A收， A知道B能发收

3：A发，B收， B知道A能收

而不用四次或更多握手，是因为：

三次是保证双方互相明确对方能收能发的最低值。

理论上讲不论握手多少次都不能确认一条信道是“可靠”的，但通过3次握手可以至少确认它是“可用”的，再往上加握手次数不过是提高“它是可用的”这个结论的可信程度。

1

然后，待到断开连接时，需要进行四次挥手（因为是全双工的，所以需要四次挥手）

四次挥手的步骤：（抽象派）

1. 主动方：我已经关闭了向你那边的主动通道了，只能被动接收了

2. 被动方：收到通道关闭的信息

3. 被动方：那我也告诉你，我这边向你的主动通道也关闭了

4. 主动方：最后收到数据，之后双方无法通信

详细有以下知识点：

客户端请求关闭连接，发送FIN = 1, seq = u

服务器接收到客户端的关闭请求，返回ACK，返回ACK = 1, seq = v， ack = u + 1

此时服务器可以关闭读通道了，因为客户端不会再发送数据了

此时服务器还可以继续发送数据

服务端接收到ACK后，关闭写通道，它可以不再写数据了

服务器数据发送数据完毕，也要关闭连接了，发送FIN = 1, ACK = 1, seq = w, ack = u + 1

客户端收到该消息后，可以关闭读通道了，因为服务器不会再发送数据了

客户端发送最后的ACK，服务端关闭写通道，关闭连接，发送ACK = 1, seq = u + 1, ack = w + 1

客户端发送最后的ACK后还要等待2MSL。1.护送最后的ACK，避免服务端没收到，又发来FIN重传。2.假如连接立马释放，而客户端和服务器的ip和端口刚好被别的客户端和服务器占用，则新的客户端和服务器会收到不属于它们的报文。为此等待2MSL，使得链路中的原始报文都消失掉。2MSL的原因是，1MSL等待一方报文消失，1MSL等待报文ACK消失

DNS查询用的是UDP协议，DNS协议工作在应用层，使用53号端口，UDP协议工作在传输层

4.五层协议：

1.应用层(dns,http) DNS解析成IP并发送http请求

2.传输层(tcp,udp) 建立tcp连接（三次握手）

3.网络层(IP,ARP) IP寻址

4.数据链路层(PPP) 封装成帧

5.物理层(利用物理介质传输比特流) 物理传输（然后传输的时候通过双绞线，电磁波等各种介质）

5.HTTP长连接和短连接原理浅析

1. HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另一端收到发端发出的所有包，并且顺序与发出顺序一致。TCP有可靠，面向连接的特点。

2. 如何理解HTTP协议是无状态的

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

3. 什么是长连接、短连接？

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

3.1 TCP连接

当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接 时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的

经典的三次握手示意图：

经典的四次握手关闭图：

3.2 TCP短连接

我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server 发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起 close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在 client/server间传递一次读写操作

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段

3.3 TCP长连接

接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

首先说一下TCP/IP详解上讲到的TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务 器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：

客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。

客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。

客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。

客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

3.4 长连接短连接操作过程

短连接的操作步骤是：

建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是：

建立连接——数据传输...（保持连接）...数据传输——关闭连接

4. 长连接和短连接的优点和缺点

由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

5. 什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

6.Java中List几种去重方式的比较

用JDK提供的Set对元素进行去重

Set<Integer> set = new HashSet<>(list);

用普通方法对List进行去重 for()循环剔除重复元素

用JDK1.8 Stream中对List进行去重

list.stream().distinct();

7.乐观锁和悲观锁

一、概念

悲观锁：总是假设最坏的情况，认为竞争总是存在，每次拿数据的时候都认为会被修改，因此每次都会先上锁。其他线程阻塞等待释放锁。
乐观锁：总是假设最好的情况，认为竞争总是不存在，每次拿数据的时候都认为不会被修改，因此不会先上锁，在最后更新的时候比较数据有无更新，可通过版本号或CAS实现。

二、两种锁的使用场景

悲观锁：用于写比较多的情况，避免了乐观锁不断重试从而降低性能
乐观锁：用于读比较多的情况，避免了不必要的加锁的开销

三、乐观锁的实现方式

版本号机制:
一般通过在数据库增加version列实现。

CAS（compare and swap）：

需要三个操作数
需要读写的内存值 V
进行比较的值 A
拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

四、乐观锁的缺点

1.ABA问题
2.自旋时间CPU开销大
3.JUC包下的原子类只能包含一个变量的原子操作，但是1.5之后的AtomicReference，能够保证引用对象的原子性。

五、CAS与synchronized的使用情景

CAS属于乐观锁，适用于写比较少的情况，冲突较少
synchronized属于悲观锁，适用于冲突写比较多的情况，冲突较多

竞争较少的场景：synchronized会阻塞和唤醒线程并在用户态和内核态切换浪费消耗cpu资源。CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。
竞争严重的场景：CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

8.HashMap底层实现原理 扩容机制

实现原理：

HashMap本质是一个一定长度的数组，数组中存放的是链表。

它是一个Entry类型的数组，Entry的源码：

static class Entry<K,V> implements Map.Entry<K,V> {

final K key;

V value;

final int hash;

Entry<K,V> next;

}

其中存放了Key，Value，hash值，还有指向下一个元素的引用。

当向HashMap中put(key,value)时，会首先通过hash算法计算出存放到数组中的位置，比如位置索引为i，将其放入到Entry[i]中，如果这个位置上面已经有元素了，那么就将新加入的元素放在链表的头上，最先加入的元素在链表尾。比如，第一个键值对A进来，通过计算其key的hash得到的index=0，记做:Entry[0] = A。一会后又进来一个键值对B，通过计算其index也等于0，现在怎么办？HashMap会这样做:B.next = A,Entry[0] = B,如果又进来C,index也等于0,那么C.next = B,Entry[0] = C；这样我们发现index=0的地方其实存取了A,B,C三个键值对,他们通过next这个属性链接在一起,也就是说数组中存储的是最后插入的元素。

HashMap的get(key)方法是：首先计算key的hashcode，找到数组中对应位置的某一元素，然后通过key的equals方法在对应位置的链表中找到需要的元素。从这里我们可以想象得到，如果每个位置上的链表只有一个元素，那么hashmap的get效率将是最高的。所以我们需要让这个hash算法尽可能的将元素平均的放在数组中每个位置上。

扩容机制：

当HashMap中的元素越来越多的时候，hash冲突的几率也就越来越高，因为数组的长度是固定的。所以为了提高查询的效率，就要对HashMap的数组进行扩容。

HashMap的容量由一下几个值决定：

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4;      // HashMap初始容量大小(16)

static final int MAXIMUM_CAPACITY = 1 << 30;               // HashMap最大容量

transient int size;                                       // The number of key-value mappings contained in this map

static final float DEFAULT_LOAD_FACTOR = 0.75f;          // 负载因子

HashMap的容量size乘以负载因子[默认0.75] = threshold;  // threshold即为开始扩容的临界值

transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;    // HashMap的基本构成Entry数组

当HashMap中的元素个数超过数组大小(数组总大小length,不是数组中个数size)*loadFactor时，就会进行数组扩容，loadFactor的默认值为0.75，这是一个折中的取值。也就是说，默认情况下，数组大小为16，那么当HashMap中元素个数超过16*0.75=12（这个值就是代码中的threshold值，也叫做临界值）的时候，就把数组的大小扩展为 2*16=32，即扩大一倍，然后重新计算每个元素在数组中的位置。

0.75这个值成为负载因子，那么为什么负载因子为0.75呢？这是通过大量实验统计得出来的，如果过小，比如0.5，那么当存放的元素超过一半时就进行扩容，会造成资源的浪费；如果过大，比如1，那么当元素满的时候才进行扩容，会使get,put操作的碰撞几率增加。

HashMap中扩容是调用resize()方法，方法源码：

void resize(int newCapacity) {

Entry[] oldTable = table;

int oldCapacity = oldTable.length;

//如果当前的数组长度已经达到最大值，则不在进行调整

if (oldCapacity == MAXIMUM_CAPACITY) {

threshold = Integer.MAX_VALUE;

return;

}

//根据传入参数的长度定义新的数组

Entry[] newTable = new Entry[newCapacity];

//按照新的规则，将旧数组中的元素转移到新数组中

transfer(newTable);

table = newTable;

//更新临界值

threshold = (int)(newCapacity * loadFactor);

}

//旧数组中元素往新数组中迁移

void transfer(Entry[] newTable) {

//旧数组

Entry[] src = table;

//新数组长度

int newCapacity = newTable.length;

//遍历旧数组

for (int j = 0; j < src.length; j++) {

Entry<K,V> e = src[j];

if (e != null) {

src[j] = null;

do {

Entry<K,V> next = e.next;

int i = indexFor(e.hash, newCapacity);//放在新数组中的index位置

e.next = newTable[i];//实现链表结构，新加入的放在链头，之前的的数据放在链尾

newTable[i] = e;

e = next;

} while (e != null);

}

}

}

可以看到HashMap不是无限扩容的，当达到了实现预定的MAXIMUM_CAPACITY，就不再进行扩容。

Hashmap为什么大小是2的幂次？

因为在计算元素该存放的位置的时候，用到的算法是将元素的hashcode与当前map长度-1进行与运算。源码：

static int indexFor(int h, int length) {

// assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";

return h & (length-1);

}

如果map长度为2的幂次，那长度-1的二进制一定为11111...这种形式，进行与运算就看元素的hashcode，但是如果map的长度不是2的幂次，比如为15，那长度-1就是14，二进制为1110，无论与谁相与最后一位一定是0，0001，0011，0101，1001，1011，0111，1101这几个位置就永远都不能存放元素了，空间浪费相当大。也增加了添加元素是发生碰撞的机会。减慢了查询效率。所以Hashmap的大小是2的幂次。

get方法实现

Hashmap get一个元素是，是计算出key的hashcode找到对应的entry，这个时间复杂度为O(1)，然后通过对entry中存放的元素key进行equal比较，找出元素，这个的时间复杂度为O(m)，m为entry的长度。

9.运算符

1.十进制转二进制

原理：给定的数循环除以2，直到商为0或者1为止。将每一步除的结果的余数记录下来，然后反过来就得到相应的二进制了。

比如8转二进制，第一次除以2等于4（余数0），第二次除以2等于2（余数0），第三次除以2等于1（余数0），最后余数1，得到的余数依次是0 0 0 1 ，

反过来就是1000，计算机内部表示数的字节长度是固定的，比如8位，16位，32位。所以在高位补齐，java中字节码是8位的，所以高位补齐就是00001000.

写法位（8）10=（00001000）2；

代码实现：

1 package sourceCode.hashMap;

2

3 public class mapHashCodeTest {

4     public static void main(String[] args) {

5         String str = toBinary(8);

6         System.out.println(str);

7     }

8

9     static String toBinary(int num) {

10         String str = "";

11         while (num != 0) {

12             str = num % 2 + str;

13             num = num / 2;

14         }

15         return str;

16     }

17

18 }

运行结果：1000

2.二进制转十进制

计算也很简单，比如8的二进制表示位00001000，去掉补齐的高位就是1000.此时从个位开始计算2的幂（个位是0，依次往后推）乘以对应位数上的数，然后得到的值想加

于是有了，（2的0次幂）*0+（2的1次幂）*0+（2的2次幂）*0+（2的3次幂）*1 = 8

代码实现，直接调用Integer.parseInt("",2);

1 System.out.println(Integer.parseInt("1000",2));

运行结果：8

3.位异或运算（^）

运算规则是：两个数转为二进制，然后从高位开始比较，如果相同则为0，不相同则为1。

比如：8^11.

8转为二进制是1000，11转为二进制是1011.从高位开始比较得到的是：0011.然后二进制转为十进制，就是Integer.parseInt("0011",2)=3;

4.位与运算符（&）

运算规则：两个数都转为二进制，然后从高位开始比较，如果两个数都为1则为1，否则为0。

比如：129&128.

129转换成二进制就是10000001，128转换成二进制就是10000000。从高位开始比较得到，得到10000000，即128.

 5.位或运算符（|）

运算规则：两个数都转为二进制，然后从高位开始比较，两个数只要有一个为1则为1，否则就为0。

比如：129|128.

129转换成二进制就是10000001，128转换成二进制就是10000000。从高位开始比较得到，得到10000001，即129.

6.位非运算符（~）

运算规则：如果位为0，结果是1，如果位为1，结果是0.

比如：~37

在Java中，所有数据的表示方法都是以补码的形式表示，如果没有特殊说明，Java中的数据类型默认是int,int数据类型的长度是8位，一位是四个字节，就是32字节，32bit.

8转为二进制是100101.

补码后为： 00000000 00000000 00000000 00100101

取反为：    11111111 11111111 11111111 11011010

因为高位是1，所以原码为负数，负数的补码是其绝对值的原码取反，末尾再加1。

因此，我们可将这个二进制数的补码进行还原： 首先，末尾减1得反码：11111111 11111111 11111111 11011001 其次，将各位取反得原码：

00000000 00000000 00000000 00100110，此时二进制转原码为38

所以~37 = -38.

<<      :     左移运算符，num << 1,相当于num乘以2

>>      :     右移运算符，num >> 1,相当于num除以2

>>>    :     无符号右移，忽略符号位，空位都以0补齐

10.ConcurrentHashMap,put值时key和value都不能为空

if (key == null || value == null) throw new NullPointerException();

调用hashCode时调用传入对象的hashcode，如果没有重写hashcode，默认调用object的native的hashcode方法

11.Java-五种线程池，四种拒绝策略，三种阻塞队列

三种阻塞队列：

BlockingQueue<Runnable> workQueue = null;

workQueue = new ArrayBlockingQueue<>(5) ;//基于数组的先进先出队列，有界

workQueue = new LinkedBlockingQueue<>() ;//基于链表的先进先出队列，无界

workQueue = new SynchronousQueue<>();    //无缓冲的等待队列，无界

四种拒绝策略：

RejectedExecutionHandler rejected = null;

rejected = new ThreadPoolExecutor.AbortPolicy();//默认，队列满了丢任务抛出异常

rejected = new ThreadPoolExecutor.DiscardPolicy();//队列满了丢任务不异常

rejected = new ThreadPoolExecutor.DiscardOldestPolicy();//将最早进入队列的任务删，之后再尝试加入队列

rejected = new ThreadPoolExecutor.CallerRunsPolicy();//如果添加到线程池失败，那么主线程会自己去执行该任务

五种线程池：

ExecutorService threadPool = null;

threadPool = Executors.newCachedThreadPool();//有缓冲的线程池，线程数 JVM 控制

threadPool = Executors.newFixedThreadPool(3);//固定大小的线程池

threadPool = Executors.newScheduledThreadPool(2);

threadPool = Executors.newSingleThreadExecutor();//单线程的线程池，只有一个线程在工作

threadPool = new ThreadPoolExecutor();//默认线程池，可控制参数比较多

12.Map、Set、List是否有序

首先明确概念：这里的有序和无序不是指集合中的排序，而是是否按照元素添加的顺序来存储对象。

list是按照元素的添加顺序来存储对象的，因此是有序的。他的实现类ArrayList、LinkedList、Vector都是有序的。

HashMap JDK1.8中对hash算法做了调整，key是int型的或者可以转换为int型的，算法会自动按排序的结果插入到map中去。 如下图：

Map<String,String> map=new HashMap<>();
map.put("13","13");
map.put("14","14");
map.put("12", "12");
map.put("15","15");
int size=map.size();

Map是无序的，它的存储结构是哈希表<key,value>键值对，map中插入元素是根据key计算出的哈希值来存储元素的，因此他不是按照元素的添加顺序来存储对象的，所以Map是无序的。它的实现类有：HashMap、TableMap和TreeMap。

其中LinkedHashMap是有序的，hashMap用来保证存储的值键值对，list用来保证插入的顺序和存储的顺序一致。

Set是无序的，并且set中的元素不能重复。set的底层实现其实是Map，它是计算key的哈希值来确定元素在数组中的存放位置，所以是无序的，应为在Map中key的值不能重复，所以set中的元素不能重复。它的实现类有：hashSet、TreeSet。

HashSet：

HashSet类按照哈希算法来存取集合中的对象，存取速度比较快。

1、Set中是不能出现重复数据的。

2、Set中可以出现空数据。

3、Set中的数据是无序的。

LinkedHashSet：

1、LinkedHashSet是有序的（不同于HashSet）。

2、LinkedHashSet在迭代访问Set中的全部元素时，性能比HashSet好，但是插入时性能稍微逊色于HashSet。

TreeSet：

1.不能写入空数据

2.写入的数据是有序的。

3.不写入重复数据

13.重写对象的equals()方法

首先直接使用==判断这两个对象的地址是否相同，如果相同，直接返回true;

判断输入参数对象的类是否instanceof当前对象所在的类，如果不是，直接返回false;

然后判断当前对象和要与之equals()的对象是否为空，1）为空判断当前对象是否为空，也为空，返回true；2）不为空，调用Object的equals 方法。如下                      return o1 == null ? o2 == null : o1.equals(o2);

14.Redis的持久化(Rdb. Aof)

Rdb(Redis Database)

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储（快照存储到内盘）；

Aof(Append Only File)

以日志的形式记录每个写操作，

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

RDB 方式与 AOF 方式的优势对比

RDB 方式的优点 

RDB 是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。

RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心，非常适用于灾难恢复。

RDB 在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 Redis 的性能。

与AOF相比,在恢复大的数据集的时候，RDB 方式会更快一些。

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:

Redis 调用forks. 同时拥有父进程和子进程。

子进程将数据集写入到一个临时 RDB 文件中。

当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

AOF 方式的优点

使用AOF 会让你的Redis更加耐久:

你可以使用不同的 fsync 策略：无 fsync、每秒 fsync 、每次写的时候 fsync .使用默认的每秒 fsync 策略, Redis 的性能依然很好( fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据。

AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

优点对比总结

RDB 方式可以保存过去一段时间内的数据，并且保存结果是一个单一的文件，可以将文件备份到其他服务器，并且在回复大量数据的时候，RDB 方式的速度会比 AOF 方式的回复速度要快。

AOF 方式默认每秒钟备份1次，频率很高，它的操作方式是以追加的方式记录日志而不是数据，并且它的重写过程是按顺序进行追加，所以它的文件内容非常容易读懂。可以在某些需要的时候打开 AOF 文件对其编辑，增加或删除某些记录，最后再执行恢复操作。

RDB 方式与 AOF 方式的缺点对比

RDB 方式的缺点

如果你希望在 Redis 意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么 RDB 不适合你.虽然你可以配置不同的save时间点(例如每隔 5 分钟并且对数据集有 100 个写的操作),是 Redis 要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在 Redis 意外宕机,你可能会丢失几分钟的数据。

RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候, fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且 CPU 性能不是很好的情况下,这种情况会持续1秒, AOF 也需要 fork ,但是你可以调节重写日志文件的频率来提高数据集的耐久度。

AOF 方式的缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

缺点对比总结

RDB 由于备份频率不高，所以在回复数据的时候有可能丢失一小段时间的数据，而且在数据集比较大的时候有可能对毫秒级的请求产生影响。

AOF 的文件提及比较大，而且由于保存频率很高，所以整体的速度会比 RDB 慢一些，但是性能依旧很高。

Redis 持久化 之 AOF 和 RDB 同时开启，Redis听谁的？

听AOF的，RDB与AOF同时开启 默认无脑加载AOF的配置文件
相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB
AOF运行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同

15.Redis事务使用方法 watch和unwatch

执行MULTI后，在EXEC或DISCARD之前发送的所有命令都会被Redis按顺序缓存起来，并返回QUEUED。执行EXEC后，Redis取出缓存的命令开始执行，并返回每一条命令的返回值。

使用WATCH监控的key如果发生了变化，事务将被打断。在EXEC或DISCARD执行后，WATCH监控自动失效，否则使用UNWATCH取消监控。

①执行MULTI后不能再执行WATCH，否则返回错误“WATCH inside MULTI is not allowed”；

②如果命令有语法错误Redis会报错，但是运行时出现的错误会被Redis忽略不影响后面的执行，需要自己确保不出现运行时错误；

16.主从复制原理（配从不配主slaveof 主机IP 主机端口）

主机挂了，从机进入等待状态，主机回复之后从机依旧作为从机；

从机挂了重新启动后从机状态清除，变为主机状态，必须重新设置为主机的从机或者在配置文件中写入主从关系。

Info replication 查看机器的主从状态

反客为主：slaveof no one (让当前从机变为主机)但其他从机都要手动改为主机的从机

主从多个redis集合在一起，以一个master多个slave为模式对外提供服务，配置master可读可写，配置slave提供读，这样就即能保证redis集群中的数据同步，又可以实现redis的读写分离，如果写比较多的情况一般就以异步的形式提供服务

redis主从复制可以根据是否是全量分为全量同步和增量同步

全量同步，一般发生在slave初始化阶段，这时slave需要将master上的所有数据都复制一份增量同步，slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程，增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令

redis主从同步策略主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。如果有需

要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步

注意：如果多个slave断线了，需要重启的时候，因为只要slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机

17.哨兵机制

哨兵是一个分布式系统，可以在一个架构中运行多个哨兵，该系统执行以下三个任务：

监控：哨兵会不断地检查master和slave是否运行正常，只需配置主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知

提醒：当被监控的redis出现问题时，哨兵通过API向管理员或其他程序发送通知

自动故障迁移：当一个master不能正常工作时，它会将失效master中的一个slave 升级为新的master（这个master可以进行读写操作），并让失效master的其他 slave改为复制新的master，当客户端试图连接到失效master时，集群也会向客户端返回新的master的地址，使得集群可以使用master代替失效的master，如果之前的主服务器恢复，会自动跟随新选举出来的master成为slave

哨兵的工作方式：每隔一秒哨兵会向它所知的master，slave以及其他哨兵发送一次ping命令做一次心跳检测，如果ping的时间超过指定值，哨兵节点则认为该节点错误或下线，主观下线

如果一个master被标记为主观下线，则监视这个master的所有哨兵都要以每秒一次的频率确认master的确进入了主观下线状态，当有足够数量的哨兵（大于配置文件的值）确认master进入主观下线状态，则master会标记为客观下线

18.缓存穿透及优化

缓存穿透是指查询一个不存在的key数据，由于缓存没命中需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，流量大时DB会挂掉，这也是经常提的缓存命中率

问题解决：

1.如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴

2.在控制层对要查询的key进行校验，不符合则丢弃，然后再放行给后面的正常缓存处理逻辑

19. 缓存雪崩及优化

缓存雪崩是由于大量的key设置了相同的过期时间，原有缓存失效，新缓存未到期间。所有请求都去查询数据库，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机造成整个系统崩溃

为什么设置过期时间：比如我们在发送手机验证码的时候，将手机号作为redis key，验证码作为redis value存储在redis中，并设置过期时间为60秒，如果60秒的时间到了，懂了没？

解决：

1.一般并发量不是特别多的时候，使用最多的解决方案是加锁排队

2.高并发下给每一个缓存数据增加相应的缓存标记，用来记录缓存的是否失效，如果缓存标记失效，则更新数据缓存

3.简单有效的方法：缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低

20.MYSQL

UNION

UNION 操作符用于合并两个或多个 SELECT 语句的结果集。

请注意，UNION 内部的 SELECT 语句必须拥有相同数量的列。列也必须拥有相似的数据类型。同时，每条 SELECT 语句中的列的顺序必须相同。

注释：默认地，UNION 操作符选取不同的值。如果允许重复的值，请使用 UNION ALL。

UNION 结果集中的列名总是等于 UNION 中第一个 SELECT 语句中的列名。

mysql中join的7种连接方式

mysql中join的7种连接方式https://blog.csdn.net/qq_32296307/article/details/81812589.

索引(where的查找速度orderby的排序)

索引是对数据库表中一列或多列的值进行排序的一种数据结构，使用索引可快速访问数据库表中的特定信息。索引的一个主要目的就是加快检索表中数据，亦即能协助信息搜索者尽快的找到符合限制条件的记录ID的辅助数据结构

数据库索引好比是一本书前面的目录，能加快数据库的查询速度。

建立索引的目的是加快对表中记录的查找或排序。但为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。

优点

在设计数据库时，通过创建一个惟一的索引，能够在索引和信息之间形成一对一的映射式的对应关系，增加数据的惟一性特点。

能提高数据的搜索及检索速度，符合数据库建立的初衷。

能够加快表与表之间的连接速度，这对于提高数据的参考完整性方面具有重要作用。

在信息检索过程中，若使用分组及排序子句进行时，通过建立索引能有效的减少检索过程中所需的分组及排序时间，提高检索效率。

建立索引之后，在信息查询过程中可以使用优化隐藏器，这对于提高整个信息检索系统的性能具有重要意义。

缺点

在数据库建立过程中，需花费较多的时间去建立并维护索引，特别是随着数据总量的增加，所花费的时间将不断递增。

在数据库中创建的索引需要占用一定的物理存储空间，这其中就包括数据表所占的数据空间以及所创建的每一个索引所占用的物理空间，如果有必要建立起聚簇索引，所占用的空间还将进一步的增加

在对表中的数据进行修改时，例如对其进行增加、删除或者是修改操作时，索引还需要进行动态的维护，这给数据库的维护速度带来了一定的麻烦。

有利于建索引的条件

在经常需要搜索的列上，可以加快搜索的速度；

在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；

在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；

在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；

在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

不利于建索引的情况

第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。

第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。

第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少,不利于使用索引。

第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改操作远远多于检索操作时，不应该创建索引。

操作实例

1. SELECT * FROM mytable WHERE category_id=1;

最直接的应对之道，是为category_id建立一个简单的索引：

CREATE INDEX mytable_categoryid ON mytable (category_id);

OK.如果有不止一个选择条件呢？例如：

SELECT * FROM mytable WHERE category_id=1 AND user_id=2;

第一反应可能是，再给user_id建立一个索引。不好，这不是一个最佳的方法。可以建立多重的索引。

CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);

-----使用orderby------

21.java 字符流与字节流哪个快

Java 流在处理上分为字符流和字节流。字符流处理的单元为 2 个字节的 Unicode 字符，分别操作字符、字符数组或字符串，而字节流处理单元为 1 个字节，操作字节和字节数组。

Java 内用 Unicode 编码存储字符，字符流处理类负责将外部的其他编码的字符流和 java 内 Unicode 字符流之间的转换。而类 InputStreamReader 和 OutputStreamWriter 处理字符流和字节流的转换。字符流（一次可以处理一个缓冲区）一次操作比字节流（一次一个字节）效率高。

22.http与https连接建立

HTTPS是在HTTP的基础上和ssl/tls证书结合起来的一种协议,保证了传输过程中的安全性,减少了被恶意劫持的可能.很好的解决了http的三个缺点（被监听、被篡改、被伪装）。

建立连接

  • HTTP和HTTPS都需要在建立连接的基础上来进行数据传输,是基本操作
  • 当客户在浏览器中输入网址的并且按下回车,浏览器会在浏览器DNS缓存,本地DNS缓存,和Hosts中寻找对应的记录,如果没有获取到则会请求DNS服务来获取对应的ip
  • 当获取到ip后,tcp连接会进行三次握手建立连接

tcp的三次挥手和四次挥手

三次挥手(建立连接)

  • 第一次：建立连接时，客户端发送SYN包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
  • 第二次：服务器收到SYN包，向客户端返回ACK（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RCVD状态；
  • 第三次：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
  • 完成三次握手，客户端与服务器开始传送数据，也就是ESTABLISHED状态。
  • 三次握手保证了不会建立无效的连接，从而浪费资源。

四次挥手(断开连接)

  • 第一次： TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
  • 第二次：服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
  • 第三次：服务器关闭客户端的连接，发送一个FIN给客户端。
  • 第四次：客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

HTTP请求过程

  • 建立连接完毕以后客户端会发送响应给服务端
  • 服务端接受请求并且做出响应发送给客户端
  • 客户端收到响应并且解析响应响应给客户

HTTPS

  • 在使用HTTPS是需要保证服务端配置正确了对应的安全证书
  • 客户端发送请求到服务端
  • 服务端返回公钥和证书到客户端
  • 客户端接收后会验证证书的安全性,如果通过则会随机生成一个随机数,用公钥对其加密,发送到服务端
  • 服务端接受到这个加密后的随机数后会用私钥对其解密得到真正的随机数,随后用这个随机数当做私钥对需要发送的数据进行对称加密
  • 客户端在接收到加密后的数据使用私钥(即生成的随机值)对数据进行解密并且解析数据呈现结果给客户
  • SSL加密建立

23.数据库四大特性和事务隔离级别

数据库中经常被问到四大特性和隔离级别，一般都是涉及到概念性问题，在此做一些整理总结，方便理解。

1、事务的隔离级别

由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

（1）Read uncommitted(未授权读取、读未提交)：

1）其他事务读未提交数据，出现脏读；
2）如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
3）避免了更新丢失，却可能出现脏读。也就是说事务B读取到了事务A未提交的数据。
（读未提交：一个事务写数据时，只允许其他事务对这行数据进行读，所以会出现脏读，事务T1读取T2未提交的数据）

（2）Read committed（授权读取、读提交）：

1）允许写事务，所以会出现不可重复读
2）读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
3）该隔离级别避免了脏读，但是却可能出现不可重复读。事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
（读已提交：读取数据的事务允许其他事务进行操作，避免了脏读，但是会出现不可重复读，事务T1读取数据，T2紧接着更新数据并提交数据，事务T1再次读取数据的时候，和第一次读的不一样。即虚读）

（3）Repeatable read（可重复读取）：

1）禁止写事务；
2）读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
3）避免了不可重复读取和脏读，但是有时可能出现幻读。这可以通过“共享读锁”和“排他写锁”实现。
（可重复读：读事务会禁止所有的写事务，但是允许读事务，避免了不可重复读和脏读，但是会出现幻读，即第二次查询数据时会包含第一次查询中未出现的数据）

（4）Serializable（序列化）：

1）禁止任何事务，一个一个进行；
2）提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
3）序列化是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻读。

2、出现的问题：

当多个线程都开启事务操作数据库中的数据时，数据库系统要能进行隔离操作，以保证各个线程获取数据的准确性，在介绍数据库提供的各种隔离级别之前，我们先看看如果不考虑事务的隔离性，会发生的几种问题：脏读、不可重复读、幻读。

（1）脏读

1.脏读定义：

1）说法1：指在一个事务处理过程里读取了另一个未提交的事务中的数据，读取数据不一致。
  2）说法2：指事务A对数据进行增删改操作，但未提交，另一事务B可以读取到未提交的数据。如果事务A这时候回滚了，则第二个事务B读取的即为脏数据。

2.举例：

当一个事务正在多次修改某个数据，而在这个事务中多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。
例如：用户A向用户B转账100元，对应SQL命令如下
　　update account set money=money+100 where name=’B’; (此时A通知B)
　　update account set money=money - 100 where name=’A’;
当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。

（2）不可重复读

1.不可重复读定义：

1）说法1：是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。
  2）说法2：一个事务A中发生了两次读操作，第一次读操作和第二次读操作之间，另一个事务B对数据进行了修改，这时两个事务读取的数据不一致。

2.举例：

例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。

3.不可重复读和脏读的区别：

脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。
  在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如对于同一个数据A和B依次查询就可能不同，A和B就可能打起来了……

（3）虚读(幻读)

1.幻读定义：

1）说法1：是事务非独立执行时发生的一种现象。
  2）说法2：第一个事务A对一定范围的数据进行批量修改，第二个事务B在这个范围增加一条数据，这时候第一个事务就会丢失对新增数据的修改。

2.举例：

例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。

3.幻读和不可重复读区别：

都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

3、MySQL数据库提供的四种隔离级别：

•   ① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
•   ② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
•   ③ Read committed (读已提交)：可避免脏读的发生。
•   ④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。

以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。
　　在MySQL数据库中，支持上面四种隔离级别，默认的为Repeatable read (可重复读)；而在Oracle数据库中，只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别，其中默认的为Read committed级别。
1）在MySQL数据库中查看当前事务的隔离级别：

select @@tx_isolation;

2）在MySQL数据库中设置事务的隔离 级别：

set  [glogal | session]  transaction isolation level 隔离级别名称;
set tx_isolation=’隔离级别名称;’

例1：查看隔离级别：

查看当前事务的隔离级别

例2：将事务的隔离级别设置为（Repatable read）可重复读或者Read uncommitted级别：

设置隔离级别(1)

或者

设置隔离级别(2)

注意：设置数据库的隔离级别一定要是在开启事务之前！
　　如果是使用JDBC对数据库的事务设置隔离级别的话，也应该是在调用Connection对象的setAutoCommit(false)方法之前。调用Connection对象的setTransactionIsolation(level)即可设置当前链接的隔离级别，至于参数level，可以使用Connection对象的字段：

Connection对象的字段

在JDBC中设置隔离级别的部分代码：

JDBC设置隔离级别

4、事务的四大特性

数据库中事务的四大特性（ACID）：原子性、一致性、隔离性、持久性。如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性：

（1）原子性（Atomicity）

原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

（2）一致性（Consistency）

一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
  如：拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。

（3）隔离性（Isolation）

隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
  即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

（4）持久性（Durability）

持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
  例如：我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

后记：其实说来说去也就三方面的概念
1）四大隔离级别：串行化、可重复读、读已提交、读未提交；
2）四大特性(ACID)：原子性、一致性、隔离性、持久性；
3）三个问题：脏读、不可重复度、幻读；

24.处理高并发的六种方法

1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。

4：分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6：solrCloud:
SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解决海量数据的 分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡,可以做到负载均衡：

25. 高并发的解决方案

1.应用和静态资源分离

刚开始的时候应用和静态资源是保存在一起的，当并发量达到一定程度的时候就需要将静态资源保存到专门的服务器中，静态资源主要包括图片、视频、js、css和一些资源文件等，这些文件因为没有状态所以分离比较简单，直接存放到响应的服务器就可以了，一般会使用专门的域名去访问。

通过不同的域名可以让浏览器直接访问资源服务器而不需要再访问应用服务器了。架构图如下：

2.页面缓存

页面缓存是将应用生成的页面缓存起来，这样就不需要每次都生成页面了，从而可以节省大量的CPU资源，如果将缓存的页面放到内存中速度就更快了。如果使用Nginx服务器就可以使用它自带的缓存功能，当然也可以使用专门的Squid 服务器。页面缓存的默认失效机制一班都是按缓存时间处理的，当然也可以在修改数据之后手动让相应的缓存失效。

页面缓存主要是使用在数据很少发生变化的页面，但是很多页面是大部分数据都很少发生变化，而其中很少一部分数据变化频率却非常高，比如说一个显示文章的页面，正常来说完全可以静态化，但是如果文章后面有“顶”和“踩”的功能而且显示的有响应的数量，这个数据的变化频率就比较高了，这就会影响静态化。这个问题可以用先生成静态页面然后使用Ajax来读取并修改响应的数据，这样就可以一举两得来，既可以使用页面缓存也可以实时显示一些变化频率高的数据来。

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

3.集群与分布式

集群是每台服务器都具有相同的功能，处理请求时调用那台服务器都可以，主要起分流作用。

分布式是将不同的业务放到不同的服务器中，处理一个请求可能需要用到多台服务器，这样就可以提高一个请求的处理速度，而且集群和分布式也可以同时使用。

集群有两个方式：一种是在静态资源集群。另一种是应用程序集群。静态资源集群比较简单。应用程序集群在处理过程中最核心的问题就是Session 同步问题。

Session 同步有两种处理方式：一种是在Session 发生变化后自动同步到其他服务器，另一种就是用个程序统一管理Session。所有集群的服务器都使用同一个Session，Tomcat 默认使用就是第一种方式，通过简单的配置就可以实现，第二种方式可以使用专门的服务器安装Mencached等高效的缓存程序统一来管理session，然后再应用程序中通过重写Request并覆盖getSession 方法来获取制定服务器中的Session。

对于集群来说还有一个核心的问题就是负载均衡，也就是接收到一个请求后具体分配到那个服务器去处理的问题，这个问题可以通过软件处理也可以使用专门的硬件（如：F5）解决。

4. 反向代理

反向代理指的是客户端直接访问的服务器并不真正提供服务，它从别的服务器获取资源然后将结果返回给用户。

图：

4.1 反向代理服务器和代理服务器的区别

代理服务器的作用是代我门获取想要的资源然后将结果返回给我们，所要获取的资源是我门主动告诉代理服务器的，比如，我门想访问Facebook，但是直接访问不了，这时就可以让代理服务器访问，然后将结果返回给我们。

反向代理服务器是我门正常访问一台服务器的时候，服务器自己去调用了别的服务器资源并将结果返回给我们，我门自己并不知道。

代理服务器是我们主动使用的，是为我们服务的，他不需要有自己的域名；反向代理服务器是服务器自己试用的，我门并不知道，它有自己的域名，我门访问它和访问正常的网址没有任何区别。

4.2反向代理服务器主要有三个作用：

1. 可以作为前端服务器跟实际处理请求的服务器集成；

2. 可以做负载均衡

3. 转发请求，比如说可以将不同类型的资源请求转发到不同的服务器去处理。

5. CDN

cdn其实是一种特殊的集群页面缓存服务器，他和普通集群的多台页面缓存服务器相比，主要是它存放的位置和分配请求的方式有点特殊。CDN 服务器是分布在全国各地的，当接收到用户请求后会将请求分配到最合适的CDN服务器节点获取数据。比如联通的用户分配到联通的节点，上海的用户分配到上海的节点。

CDN的每个节点其实就是一个页面缓存服务器，如果没有请求资源的缓存就会从主服务器获取，否则直接返回缓存的页面。

CDN分配请求（负载均衡）的方式是用专门的CDN域名解析服务器在解析域名的时候就分配好的。一般的做法是在ISP哪里试用CNAME将域名解析到一个特定的域名，然后再将解析到的那个域名用专门的CDN服务器解析道相应的CDN节点。如图。

第二步访问CDN的DNS服务器是应为CNAME记录的目标域名使用NS记录指向了CDN的DNS服务器。CDN的每个节点可能也是集群了多台服务器。

6. 底层的优化

前面说的所有都是架构都是建立在最前面介绍的基础结构之上的。很多地方都需要通过网络传输数据，如果可以加快网络传输的速度，那将会让整个系统得到改善。

7.数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

8. 小结

网站架构的整个演变过程主要是围绕大数据和高并发这两个问题展开的，解决方案主要分为使用缓存和多资源两种类型。多资源主要指多存储（包括多内存）、多CPU和多网络，对于多资源来说又可以分为单个资源处理一个完整的请求和多个资源合作处理一个请求两种类型，如多存储和多CPU中的集群和分布式，多网络中的CDN和静态资源分离。理解了整个思路之后就抓住了架构演变的本质，而且自己可能还可以设计出更好的架构。

其它简单总结：

首先，我认为解决问题之前首先要有清晰的思路，如果只是用来别人的解决方案那也只能是拿来主义，没有真正理解，没有做到举一反三。

海量数据和高并发经常被连在一块说事儿，虽然他们完全是两回事儿。海量数据纯指的是数据库的海量数据，而并发指的却包括数据库和服务器的高访问量。

那么问题来了，既然是数据库的数据量大，那怎么办呢？要想解决问题，首先要知道问题是什么！！！那么海量数据会给我带来什么样的问题呢？

海量数据带来的问题无非就是增删改查的问题，除了之外还能有啥问题呢？总不能是带来安全问题吧（打脸一，还真有可能是安全问题）

1 数据库访问缓慢

2 插入更新缓慢，这个问题只能通过分库分表解决

要解决数据库访问缓慢的问题还有几种方法，既然访问数据库慢的话，在逻辑允许的情况下可以不访问数据库呢？

1 使用缓存

2 使用页面静态化

既然不访问数据库逃不过去了，那我们就对数据库进行优化

3 优化数据库（包含的内容非常多，比如参数配置，索引优化，sql优化等等）

4 分离数据库中活跃的数据

5 读写分离

6 批量读取和延迟修改；

7 使用搜索引擎搜索数据库中的数据；

8 使用NoSQL和Hadoop等技术；

9 进行业务的拆分；

高并发的解决方案

其实这个问题必须结合上面的海量数据来讨论，什么情况下会出现高并发呢？一定是平时访问量就比较大的情况，那么平时访问量比较大相应的数据存储也就越来越多，这都是相辅相成的，当然也有个例，比如刚需，比如12306，这里的高并发相比于它的数据来说已经不算海量了。那么平时访问量大如何解决呢？因为这里牵扯到服务器和数据库的问题，所以要从这两方面来进行优化

1 增加web服务器数量，也就是做集群，做负载均衡。既然一台服务器无法完成任务，那就多用几台，几台不够用机房

在通向第二种解决方法之前，还有没有除了数据库服务器之外能做的一些优化手段呢？当然有

1.1 页面缓存

1.2 cdn

1.3 反向代理

1.4 应用程序和静态资源分离（比如专供下载的资源单独放在一起，给这台服务器提供很高的带宽资源）

2 增加数据库服务器数量，同样做集群，做负载均衡。

海量数据的解决方案

1 使用缓存

好多事情都是相辅相成的，相比来说使用缓存更多是用来解决高并发问题的，因为海量数据导致了访问的缓慢，容易造成高并发问题的严重性，又因为数据库一般是web访问的瓶颈，所以我们在业务逻辑允许的情况下尽量先避免操作数据库，于是，就有了缓存。将必要的数据存放在内存中，而不必每次都去数据库中读取造成不必要的性能浪费和加快访问速度---这就是缓存带来的好处。那使用缓存以及选用管理缓存软件时应该注意些什么东西呢？

2 页面静态化---不想解释，还有什么值得去解释呢？

3 数据库优化

3.1 数据库表结构涉及

3.2 数据类型的选用

3.3 sql优化

3.4 索引优化

3.5 配置优化

需要注意的地方实在太多，应该作为单独的一章拿出来讲

4 分离数据库中的活跃数据

为什么要分离呢？说一个我实际环境中遇到的问题吧！有一个表只有10几个字段，表有130万条数据，但大小已经到了5G的数据，这本身是不太合理的，这么少的数据占用了太多的数据，说明其中有些字段存储了大量的字符串（比如说文章内容等），每次检索这个表时大部分是用不到这些大字段内容的，但却需要耗时比较长，产生很多的慢日志。这时我们可以考虑将表进行垂直切分，将活跃数据分离开来，这样能大大加快访问速度

5 读写分离

26.数据库读写分离，主从同步复制实现方法

实现思路

通过设置主从数据库实现读写分离，主数据库负责“写操作”，从数据库负责“读操作”，根据压力情况，从数据库可以部署多个提高“读”的速度，借此来提高系统总体的性能。

基础知识

要实现读写分离，就要解决主从数据库数据同步的问题,在主数据库写入数据后要保证从数据库的数据也要更新。

主服务器master记录数据库操作日志到Binary log，从服务器开启i/o线程将二进制日志记录的操作同步到relay log（存在从服务器的缓存中），另外sql线程将relay log日志记录的操作在从服务器执行。

记住这张图，接下来基于这个图实际设置主从数据库。

主从同步复制有以下几种方式：

（1）同步复制，master的变化，必须等待slave-1,slave-2,...,slave-n完成后才能返回。

（2）异步复制，master只需要完成自己的数据库操作即可，至于slaves是否收到二进制日志，是否完成操作，不用关心。MYSQL的默认设置。

（3）半同步复制，master只保证slaves中的一个操作成功，就返回，其他slave不管。这个功能，是由google为MYSQL引入的。

主从数据库设置的具体步骤

首先要有两个数据库服务器master、slave（也可以用一个服务器安装两套数据库环境运行在不同端口，slave也可以举一反三设置多个），我们穷人就买虚拟云服务器玩玩就行 0.0。以下操作假设你的两台服务器上都已经安装好了mysql服务。

1.打开mysql数据库配置文件

vim /etc/my.cnf

2.在主服务器master上配置开启Binary log，主要是在[mysqld]下面添加：

server-id=1

log-bin=master-bin

log-bin-index=master-bin.index

3.重启mysql服务

service mysql restart

ps：重启方式随意

4.检查配置效果，进入主数据库并执行

mysql> SHOW MASTER STATUS;

5.配置从服务器的 my.cnf

在[mysqld]节点下面添加：

master status
server-id=2
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin

这里面的server-id 一定要和主库的不同，如图：

slave my.cnf

配置完成后同样重启从数据库一下

service mysql restart

6.接下来配置两个数据库的关联

首先我们先建立一个操作主从同步的数据库用户，切换到主数据库执行：

mysql> create user repl;

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从xxx.xxx.xxx.xx' IDENTIFIED BY 'mysql';

mysql> flush privileges;

这个配置的含义就是创建了一个数据库用户repl，密码是mysql, 在从服务器使用repl这个账号和主服务器连接的时候，就赋予其REPLICATION SLAVE的权限， *.* 表面这个权限是针对主库的所有表的，其中xxx就是从服务器的ip地址。

进入从数据库后执行：

mysql> change master to

master_host='主xxx.xxx.xxx.xx',

master_port=3306,

master_user='repl',

master_password='mysql',

master_log_file='master-bin.000001',

master_log_pos=0;

这里面的xxx是主服务器ip，同时配置端口，repl代表访问主数据库的用户，上述步骤执行完毕后执行start slave启动配置：

mysql> start slave;

start slave

停止主从同步的命令为：

mysql> stop slave;

查看状态命令,\G表示换行查看

mysql> show slave status \G;

可以看到状态如下：

slave status

这里看到从数据库已经在等待主库的消息了，接下来在主库的操作，在从库都会执行了。我们可以主库负责写，从库负责读（不要在从库进行写操作），达到读写分离的效果。

27. 如何保证缓存与数据库的双写一致性？

最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。

  • 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应分布式session。
  • 更新的时候，先更新数据库，然后再删除缓存。

为什么是删除缓存，而不是更新缓存？

原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。

另外更新缓存的代价有时候是很高的，用到缓存才去算缓存。

你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？

其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 mybatis，hibernate，都有懒加载思想。

最初级的缓存不一致问题及解决方案

问题：先修改数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。

解决思路：先删除缓存，再修改数据库。如果数据库修改失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中。

28. 同步和异步，阻塞和非阻塞

同步和异步，阻塞和非阻塞，这几个词已经是老生常谈，但是还是有很多同学分不清楚，以为同步肯定就是阻塞，异步肯定就是非阻塞，其实他们并不是一回事。

同步和异步关注的是结果消息的通信机制：

同步：调用方需要主动等待结果的返回。

异步：不需要主动等待结果的返回，而是通过其他手段，比如状态通知，回调函数等。

阻塞和非阻塞主要关注的是等待结果返回调用方的状态：

阻塞：是指结果返回之前，当前线程被挂起，不做任何事。

非阻塞：是指结果在返回之前，线程可以做一些其他事，不会被挂起。

可以看见同步和异步，阻塞和非阻塞主要关注的点不同，有人会问同步还能非阻塞，异步还能阻塞?

当然是可以的，下面为了更好的说明它们的组合之间的意思，用几个简单的例子说明：

同步阻塞：同步阻塞基本也是编程中最常见的模型，打个比方你去商店买衣服，你去了之后发现衣服卖完了，那你就在店里面一直等，期间不做任何事(包括看手机)，等着商家进货，直到有货为止，这个效率很低。

同步非阻塞：同步非阻塞在编程中可以抽象为一个轮询模式，你去了商店之后，发现衣服卖完了。

这个时候不需要傻傻的等着，你可以去其他地方比如奶茶店，买杯水，但是你还是需要时不时的去商店问老板新衣服到了吗。

异步阻塞：异步阻塞这个编程里面用的较少，有点类似你写了个线程池，submit 然后马上 future.get()，这样线程其实还是挂起的。

有点像你去商店买衣服，这个时候发现衣服没有了，这个时候你就给老板留个电话，说衣服到了就给我打电话，然后你就守着这个电话，一直等着它响什么事也不做。这样感觉的确有点傻，所以这个模式用得比较少。

异步非阻塞：这也是现在高并发编程的一个核心，也是今天主要讲的一个核心。

好比你去商店买衣服，衣服没了，你只需要给老板说这是我的电话，衣服到了就打。然后你就随心所欲的去玩，也不用操心衣服什么时候到，衣服一到，电话一响就可以去买衣服了。

29. 在UTF-8中，一个汉字为什么需要三个字节？

UNICODE是万能编码，包含了所有符号的编码，它规定了所有符号在计算机底层的二进制的表示顺序。有关Unicode为什么会出现就不叙述了。

Unicode是针对所有计算机的使用者定义一套统一的编码规范，这样计算机使用者就避免了编码转换的问题。

Unicode定义了所有符号的二进制形式，也就是符号如何在计算机内部存储的，而且每个符号规定都必须使用两个字节来表示，也就是用16位二进制去代表一个符号，这样就导致了一个问题，英文编码的空间浪费，因为在ANSI中的符号都是一个字节来表示的，而使用了UNICODE编码就白白浪费了一个字节。也就代表着Unicode需要使用两倍的空间去存储相应的ANSI编码下的符号。虽然现在硬盘或者内存都很廉价，但是在网络传输中，这个问题就凸显出来了，你可以这样想想，本来1M的带宽在ANSI下可以代表1024*1024个字符，但是在Unicode下却只能代表1024*1024/2个字符。也就是1MB/s的带宽只能等价于512KB/s，这个很可怕啊。所以为了解决符号在网络中传输的浪费问题，就出现了UTF-8编码，Unicode transfer format -8 ，后面的8代表是以8位二进制为单位来传输符号的。

但是这样又导致了一个问题，虽然UTF-8可以使用一个字节来表示ANSI下的符号，但是对于其它类似汉语的符号，得需要两个字节来表示，所以计算机不知道如何去截取一个符号，也就是一个符号对应的二进制的截取开始位置和截取结束位置。

所以为了解决Unicode下的ANSI符号的空间浪费和网络传输下如何截取字符的问题，UTF规定：

如果一个符号只占一个字节，那么这个8位字节的第一位就为0。
如果为两个字节，那么规定第一个字节的前两位都为1，然后第一个字节的第三位为0，第二个字节的前两位为10。如果是三个字节的话，那么第一个字节的前三位为111，第四位为0，剩余的两个字节的前两位都为10。
按照这样的算法去思考一个中文字符的UTF-8是怎么表示的：一个中文字符需要两个字节来表示，两个字节一共是16位，那么UTF-8下，两个字节是不够的，因为两个字节下，第一个字节已经占据了三位：110，然后剩余的一个字节占据了两位：10，现在就只剩下11位，与Unicode下的两个字节，16位去表示任意一个字符是相悖的。所以就使用三个字节去表示非ANSI字符：三个字节下，一共是24位，第一个字节头四位是：1110，后两个字节的前两位都是：10，那么24位-8位=16位，刚好两个字节去表示Unicode下的任意一个非ANSI字符。这也就是为什么UTF-8需要使用三个字节去表示一个非ANSI字符的原因了！Unicode符号范围 | UTF-8编码方式

(十六进制) | （二进制）

--------------------+---------------------------------------------

0000 0000-0000 007F | 0xxxxxxx

0000 0080-0000 07FF | 110xxxxx 10xxxxxx

0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
跟据上表，解读UTF-8编码非常简单。如果一个字节的第一位是0，则这个字节单独就是一个字符；如果第一位是1，则连续有多少个1，就表示当前字符占用多少个字节。
题外话：
　　然，中国的汉字多达10多万，常用的汉字3500左右[08年统计]，如果用3个字节来表示，一共只有2^16(65535)种可能，不足以表示10多万的汉字。所以中日韩的超大字符集是采用的4个字节来表示的，多达6万多个。但是平时使用超大字符集的概率0.01%都不到。所以我们一般认为日常的中文在UTF-8中占三个字节 即可！
多个字节提供的位数超过了所需要的，多余的位以0补全到编码前面

30.逃逸分析

逃逸分析是是一种动态确定指针动态范围的静态分析，它可以分析在程序的哪些地方可以访问到指针。

换句话说，逃逸分析的目的是判断对象的作用域是否有可能逃出方法体

判断依据有两个

  1. 对象是否被存入堆中（静态字段或堆中对象的实例字段）
  2. 对象是否被传入未知代码中（方法的调用者和参数）

对于第一点对象是否被存入堆中，我们知道堆内存是线程共享的，一旦对象被分配在堆中，那所有线程都可以访问到该对象，这样即时编译器就追踪不到所有使用到该对象的地方了，这样的对象就属于逃逸对象

第二点是对象是否被传入未知代码中，Java 的即时编译器是以方法为单位进行编译，即时编译器会把方法中未被内联的方法当成未知代码，所以无法判断这个未知方法的方法调用会不会将调用者或参数放到堆中，所以认为方法的调用者和参数是逃逸的，如下所示

  1. public class Escape {
  2. private static User u;
  3. public static void alloc(User user) {
  4. u = user;
  5. }
  6. }

分配在堆上的好处是方法结束后自动释放对应的内存

31. 进程间通信机制有哪些？

进程间的通信方式：

  1.管道（pipe）及有名管道（named pipe）：

管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。

有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。

2.信号（signal）：

信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。

  3.消息队列（message queue）：

消息队列是消息的链接表，它克服了上两种通信方式中信号量有限的缺点，具有写权限得进程可以按照一定得规则向消息队列中添加新信息；对消息队列有读权限得进程则可以从消息队列中读取信息。

其基本思想是:根据”生产者-消费者”原理,利用内存中公用消息缓冲区实现进程之间的信息交换.

内存中开辟了若干消息缓冲区,用以存放消息.每当一个进程向另一个进程发送消息时,便申请一个消息缓冲区,并把已准备好的消息送到缓冲区,然后把该消息缓冲区插入到接收进程的消息队列中,最后通知接收进程.接收进程收到发送里程发来的通知后,从本进程的消息队列中摘下一消息缓冲区,取出所需的信息,然后把消息缓冲区不定期给系统.系统负责管理公用消息缓冲区以及消息的传递.

一个进程可以给若干个进程发送消息,反之,一个进程可以接收不同进程发来的消息.显然,进程中关于消息队列的操作是临界区.当发送进程正往接收进程的消息队列中添加一条消息时,接收进程不能同时从该消息队列中到出消息:反之也一样.

 4.共享内存（shared memory）：

可以说这是最有用的进程间通信方式。它使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据得更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。

这种通信模式需要解决两个问题：第一个问题是怎样提供共享内存；第二个是公共内存的互斥关系则是程序开发人员的责任。

5.信号量（semaphore）：

主要作为进程之间及同一种进程的不同线程之间得同步和互斥手段。

 6.套接字（socket）；

套解口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同及其间的进程通信。

32.TCP和UDP的区别和优缺点

1、TCP与UDP区别总结：

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付,Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。

3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。

4.每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP对系统资源要求较多，UDP对系统资源要求较少。

2、为什么UDP有时比TCP更有优势?

UDP以其简单、传输快的优势，在越来越多场景下取代了TCP,如实时游戏。

（1）网速的提升给UDP的稳定性提供可靠网络保障，丢包率很低，如果使用应用层重传，能够确保传输的可靠性。

（2）TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程，由于TCP内置的系统协议栈中，极难对其进行改进。

采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大，基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

33. HTTP状态码

消息

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。

100 Continue

客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。

101 Switching Protocols

服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。

只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。

102 Processing

由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

成功

编辑

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

200 OK

请求已成功，请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。

201 Created

请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 '202 Accepted'。

202 Accepted

服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。

返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。

203 Non-Authoritative Information

服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。

204 No Content

服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。

如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。

由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。

205 Reset Content

服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。

与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。

206 Partial Content

服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。

该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。

响应必须包含如下的头部域：

Content-Range 用以指示本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。

Date

ETag 和/或 Content-Location，假如同样的请求本应该返回200响应。

Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。

假如本响应请求使用了 If-Range 强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了 If-Range 弱缓存验证，那么本次响应禁止包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。

假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。

207 Multi-Status

由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。

重定向

编辑

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。

当且仅当后续的请求所使用的方法是 GET 或者 HEAD 时，用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向（例如：A->A，或者A->B->C->A），因为这会导致服务器和客户端大量不必要的资源消耗。按照 HTTP/1.0 版规范的建议，浏览器不应自动访问超过5次的重定向。

300 Multiple Choices

被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。

除非这是一个 HEAD 请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。当然，RFC 2616规范并没有规定这样的自动选择该如何进行。

如果服务器本身已经有了首选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为自动重定向的地址。此外，除非额外指定，否则这个响应也是可缓存的。

301 Moved Permanently

被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。

新的永久性的URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。

如果这不是一个 GET 或者 HEAD 请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

注意：对于某些使用 HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了一个301响应的话，接下来的重定向请求将会变成 GET 方式。

302 Move Temporarily

请求的资源临时从不同的 URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

上文有提及。

如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。

303 See Other

对应当前请求的响应可以在另一个 URL 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。

注意：许多 HTTP/1.1 版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

304 Not Modified

如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。

该响应必须包含以下的头信息：

Date，除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去（正如RFC 2068中规定的一样），缓存机制将会正常工作。

ETag 和/或 Content-Location，假如同样的请求本应返回200响应。

Expires, Cache-Control，和/或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。

假如本响应请求使用了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的 GET 请求使用了弱缓存验证），本次响应禁止包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。

假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请求。

假如接收到一个要求更新某个缓存条目的304响应，那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。

305 Use Proxy

被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。

注意：RFC 2068中没有明确305响应是为了重定向一个单独的请求，而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。

306 Switch Proxy

在最新版的规范中，306状态码已经不再被使用。

307 Temporary Redirect

请求的资源临时从不同的URI 响应请求。

新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求，否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应，因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。

如果这不是一个GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

请求错误

编辑

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。

如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。

400 Bad Request

1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。

2、请求参数有误。

401 Unauthorized

当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。

402 Payment Required

该状态码是为了将来可能的需求而预留的。

403 Forbidden

服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。

404 Not Found

请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。出现这个错误的最有可能的原因是服务器端没有这个页面。

405 Method Not Allowed

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。

鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。

406 Not Acceptable

请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。

除非这是一个 HEAD 请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。

407 Proxy Authentication Required

与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。

408 Request Timeout

请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。

409 Conflict

由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。

冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。

410 Gone

被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。

410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。

411 Length Required

服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。

412 Precondition Failed

服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。

413 Request Entity Too Large

服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。

如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。

414 Request-URI Too Long

请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括：

本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。

重定向URI “黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。

客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。

415 Unsupported Media Type

对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。

416 Requested Range Not Satisfiable

如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。

假如 Range 使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个 Content-Range 实体头，用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。

417 Expectation Failed

在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。

418 I'm a teapot

421 Too Many Connections

There are too many connections from your internet address

从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。

422 Unprocessable Entity

请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）

423 Locked

当前资源被锁定。（RFC 4918 WebDAV）

424 Failed Dependency

由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV）

425 Too Early

状态码 425 Too Early 代表服务器不愿意冒风险来处理该请求，原因是处理该请求可能会被“重放”，从而造成潜在的重放攻击。（RFC 8470） [1]

426 Upgrade Required

客户端应当切换到TLS/1.0。（RFC 2817）

449 Retry With

由微软扩展，代表请求应当在执行完适当的操作后进行重试。

451 Unavailable For Legal Reasons

该请求因法律原因不可用。（RFC 7725）

服务器错误

编辑

（5、6字头）

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。

这些状态码适用于任何响应方法。

500 Internal Server Error

服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器端的源代码出现错误时出现。

501 Not Implemented

服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。

502 Bad Gateway

作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

503 Service Unavailable

由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的方式处理它。

注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。

504 Gateway Timeout

作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

注意：某些代理服务器在DNS查询超时时会返回400或者500错误

505 HTTP Version Not Supported

服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

506 Variant Also Negotiates

由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。

507 Insufficient Storage

服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)

509 Bandwidth Limit Exceeded

服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。

510 Not Extended

获取资源所需要的策略并没有被满足。（RFC 2774）

600 Unparseable Response Headers

34.DNS原理及其解析过程

DNS 的过程？

关于DNS的获取流程：
DNS是应用层协议，事实上他是为其他应用层协议工作的，包括不限于HTTP和SMTP以及FTP，用于将用户提供的主机名解析为ip地址。
具体过程如下：
①用户主机上运行着DNS的客户端，就是我们的PC机或者手机客户端运行着DNS客户端了
②浏览器将接收到的url中抽取出域名字段，就是访问的主机名，比如

http://www.baidu.com/

, 并将这个主机名传送给DNS应用的客户端
③DNS客户机端向DNS服务器端发送一份查询报文，报文中包含着要访问的主机名字段（中间包括一些列缓存查询以及分布式DNS集群的工作）
④该DNS客户机最终会收到一份回答报文，其中包含有该主机名对应的IP地址
⑤一旦该浏览器收到来自DNS的IP地址，就可以向该IP地址定位的HTTP服务器发起TCP连接

Dns服务的工作过程

当 DNS 客户机需要查询程序中使用的名称时，它会查询本地DNS 服务器来解析该名称。客户机发送的每条查询消息都包括3条信息，以指定服务器应回答的问题。
● 指定的 DNS 域名，表示为完全合格的域名 (FQDN) 。
● 指定的查询类型，它可根据类型指定资源记录，或作为查询操作的专门类型。
● DNS域名的指定类别。
对于DNS 服务器，它始终应指定为 Internet 类别。例如，指定的名称可以是计算机的完全合格的域名，如

im.qq.com

，并且指定的查询类型用于通过该名称搜索地址资源记录。
DNS 查询以各种不同的方式进行解析。客户机有时也可通过使用从以前查询获得的缓存信息就地应答查询。DNS 服务器可使用其自身的资源记录信息缓存来应答查询，也可代表请求客户机来查询或联系其他 DNS 服务器，以完全解析该名称，并随后将应答返回至客户机。这个过程称为递归。
另外，客户机自己也可尝试联系其他的 DNS 服务器来解析名称。如果客户机这么做，它会使用基于服务器应答的独立和附加的查询，该过程称作迭代，即DNS服务器之间的交互查询就是迭代查询。
DNS 查询的过程如下图所示。

1、在浏览器中输入www . qq .com 域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。

2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。

3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。

4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。

5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(http://qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找http://qq.com域服务器，重复上面的动作，进行查询，直至找到www . qq .com主机。

6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。

解析顺序

　　1） 浏览器缓存

　　当用户通过浏览器访问某域名时，浏览器首先会在自己的缓存中查找是否有该域名对应的IP地址（若曾经访问过该域名且没有清空缓存便存在）；

　　2） 系统缓存

　　当浏览器缓存中无域名对应IP则会自动检查用户计算机系统Hosts文件DNS缓存是否有该域名对应IP；

　　3） 路由器缓存

　　当浏览器及系统缓存中均无域名对应IP则进入路由器缓存中检查，以上三步均为客服端的DNS缓存；

　　4） ISP（互联网服务提供商）DNS缓存

　　当在用户客服端查找不到域名对应IP地址，则将进入ISP DNS缓存中进行查询。比如你用的是电信的网络，则会进入电信的DNS缓存服务器中进行查找；

　　5） 根域名服务器

　　当以上均未完成，则进入根服务器进行查询。全球仅有13台根域名服务器，1个主根域名服务器，其余12为辅根域名服务器。根域名收到请求后会查看区域文件记录，若无则将其管辖范围内顶级域名（如.com）服务器IP告诉本地DNS服务器；

　　6） 顶级域名服务器

　　顶级域名服务器收到请求后查看区域文件记录，若无则将其管辖范围内主域名服务器的IP地址告诉本地DNS服务器；

　　7） 主域名服务器

　　主域名服务器接受到请求后查询自己的缓存，如果没有则进入下一级域名服务器进行查找，并重复该步骤直至找到正确纪录；

　　8）保存结果至缓存

　　本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时将该结果反馈给客户端，客户端通过这个IP地址与web服务器建立链接。

35. HTTP请求报文（请求行、请求头、请求体）

1.简介

HTTP协议（Hyper Text Transfer Protocol，超文本传输协议）,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

HTTP基于TCP/IP通信协议来传递数据。

HTTP基于客户端/服务端（C/S）架构模型，通过一个可靠的链接来交换信息，是一个无状态的请求/响应协议。

2.特点

（1）HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

（2）HTTP是媒体独立的：只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。

（3）HTTP是无状态：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

3.HTTP请求报文

HTTP请求报文由3部分组成（请求行+请求头+请求体）：

请求行：

①是请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。②为请求对应的URL地址，它和报文头的Host属性组成完整的请求URL。

③是协议名称及版本号。

请求头：

④是HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。

与缓存相关的规则信息，均包含在header中

请求体：

⑤是报文体，它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。 
HTTP请求报文头属性

Accept 

请求报文可通过一个“Accept”报文头属性告诉服务端 客户端接受什么类型的响应。 
如下报文头相当于告诉服务端，俺客户端能够接受的响应类型仅为纯文本数据啊，你丫别发其它什么图片啊，视频啊过来，那样我会歇菜的~~~

Accept:text/plain

Accept属性的值可以为一个或多个MIME类型的值（描述消息内容类型的因特网标准， 消息能包含文本、图像、音频、视频以及其他应用程序专用的数据）

cookie

客户端的Cookie就是通过这个报文头属性传给服务端的哦！如下所示：

Cookie: $Version=1; Skin=new;jsessionid=5F4771183629C9834F8382E23

服务端是怎么知道客户端的多个请求是隶属于一个Session呢？注意到后台的那个jsessionid = 5F4771183629C9834F8382E23木有？原来就是通过HTTP请求报文头的Cookie属性的jsessionid的值关联起来的！（当然也可以通过重写URL的方式将会话ID附带在每个URL的后面哦）。

Referer

表示这个请求是从哪个URL过来的，假如你通过google搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是http://www.google.com。

Cache-Control

对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的。

4.HTTP响应报文

HTTP的响应报文也由三部分组成（响应行+响应头+响应体）

响应行：

①报文协议及版本； 
②状态码及状态描述；

响应头：

③响应报文头，也是由多个属性组成；

响应体：

④响应报文体，即我们真正要的“干货”

响应状态码 

和请求报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。 
HTTP的响应状态码由5段组成：

1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急...

2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.

3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。

4xx 处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。

5xx 处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等。

以下是几个常见的状态码： 
200 OK 
你最希望看到的，即处理成功！ 
303 See Other 
我把你redirect到其它的页面，目标的URL通过响应报文头的Location告诉你。
304 Not Modified 
告诉客户端，你请求的这个资源至你上次取得后，并没有更改，你直接用你本地的缓存吧，我很忙哦，你能不能少来烦我啊！ 
404 Not Found 
你最不希望看到的，即找不到页面。如你在google上找到一个页面，点击这个链接返回404，表示这个页面已经被网站删除了，google那边的记录只是美好的回忆。
500 Internal Server Error
看到这个错误，你就应该查查服务端的日志了，肯定抛出了一堆异常，别睡了，起来改BUG去吧！

◆200 (OK): 找到了该资源，并且一切正常。

◆302/307：临时重定向，指出请求的文档已被临时移动到别处, 此文档的新的url在location响应头中给出

◆304 (NOT MODIFIED): 该资源在上次请求之后没有任何修改。这通常用于浏览器的缓存机制。

◆401 (UNAUTHORIZED): 客户端无权访问该资源。这通常会使得浏览器要求用户输入用户名和密码，以登录到服务器。

◆403 (FORBIDDEN): 客户端未能获得授权。这通常是在401之后输入了不正确的用户名或密码。

◆404 (NOT FOUND): 在指定的位置不存在所申请的资源。

常见的HTTP响应报文头属性

Cache-Control 
响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。常见的取值有private、public、no-cache、max-age，no-store，默认为private。
private:             客户端可以缓存
public:              客户端和代理服务器都可缓存（前端的同学，可以认为public和private是一样的）
max-age=xxx:   缓存的内容将在 xxx 秒后失效
no-cache:          需要使用对比缓存来验证缓存数据
no-store:           所有内容都不会缓存

默认为private，缓存时间为31536000秒（365天）也就是说，在365天内再次请求这条数据，都会直接获取缓存数据库中的数据，直接使用。

ETag 

一个代表响应服务端资源（如页面）版本的报文头属性，如果某个服务端资源发生变化了，这个ETag就会相应发生变化。它是Cache-Control的有益补充，可以让客户端“更智能”地处理什么时候要从服务端取资源，什么时候可以直接从缓存中返回响应。

Location

我们在JSP中让页面Redirect到一个某个A页面中，其实是让客户端再发一个请求到A页面，这个需要Redirect到的A页面的URL，其实就是通过响应报文头的Location属性告知客户端的，如下的报文头属性，将使客户端redirect到iteye的首页中：

Location: http://www.iteye.com

Set-Cookie 
服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的：

Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

5.cookie机制：

客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。

如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。

如果maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该Cookie即失效。

如果maxAge为0，则表示删除该Cookie。

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。

如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(0);                          // 设置生命周期为0，不能为负数

response.addCookie(cookie);                    // 必须执行这一句 输出到客户端

36. MySQL索引查询失效的几个情况：

首先，复习一下索引的创建：

普通的索引的创建：

CREATE INDEX  (自定义)索引名  ON  数据表(字段);

复合索引的创建：

CREATE INDEX  (自定义)索引名  ON  数据表(字段，字段，。。。);

删除索引：DROP INDEX 索引名;

以下通过explain显示出mysql执行的字段内容：

  • id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.
  • select_type: SELECT 查询的类型.
  • table: 查询的是哪个表
  • partitions: 匹配的分区
  • type: join 类型
  • possible_keys: 此次查询中可能选用的索引
  • key: 此次查询中确切使用到的索引.
  • ref: 哪个字段或常数与 key 一起被使用
  • rows: 显示此查询一共扫描了多少行. 这个是一个估计值.
  • filtered: 表示此查询条件所过滤的数据的百分比
  • extra: 额外的信息

 索引查询失效的几个情况：

1、like 以%开头，索引无效；当like前缀没有%，后缀有%时，索引有效。

2、or语句前后没有同时使用索引。当or左右查询字段只有一个是索引，该索引失效，只有当or左右查询字段均为索引时，才会生效

3、组合索引，不是使用第一列索引，索引失效。

4、数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型，使索引无效，产生全表扫描。（如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引）

5、在索引列上使用 IS NULL 或 IS NOT NULL操作。索引是不索引空值的，所以这样的操作不能使用索引，可以用其他的办法处理，例如：数字类型，判断大于0，字符串类型设置一个默认值，判断是否等于默认值即可。

6、在索引字段上使用not，<>，!=。不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。 优化方法： key<>0 改为 key>0 or key<0。

7、对索引字段进行计算操作、字段上使用函数。（索引为 emp(ename,empno,sal)）

8、当全表扫描速度比索引速度快时，mysql会使用全表扫描，此时索引失效。

37.Mysql 锁类型和加锁分析

一、锁类型介绍：     

MySQL有三种锁的级别：页级、表级、行级。

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。

行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

算法：

next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的Gap

Gap锁，不锁记录，仅仅记录前面的Gap

Recordlock锁（锁数据，不锁Gap）

所以其实 Next-KeyLocks=Gap锁+ Recordlock锁

二、死锁产生原因和示例

1、产生原因：

所谓死锁<DeadLock>：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。

死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。

那么对应的解决死锁问题的关键就是：让不同的session加锁有次序

2、产生示例：

案例一

需求：将投资的钱拆成几份随机分配给借款人。

起初业务程序思路是这样的：

投资人投资后，将金额随机分为几份，然后随机从借款人表里面选几个，然后通过一条条select for update 去更新借款人表里面的余额等。

例如两个用户同时投资，A用户金额随机分为2份，分给借款人1，2

B用户金额随机分为2份，分给借款人2，1

由于加锁的顺序不一样，死锁当然很快就出现了。

对于这个问题的改进很简单，直接把所有分配到的借款人直接一次锁住就行了。

Select * from xxx where id in (xx,xx,xx) for update //for update 加行级锁

在in里面的列表值mysql是会自动从小到大排序，加锁也是一条条从小到大加的锁

例如（以下会话id为主键）：

Session1:

mysql> select * from t3 where id in (8,9) for update;

+----+--------+------+---------------------+

| id | course | name | ctime               |

+----+--------+------+---------------------+

|  8 | WA     | f    | 2016-03-02 11:36:30 |

|  9 | JX     | f    | 2016-03-01 11:36:30 |

+----+--------+------+---------------------+

rows in set (0.04 sec)

Session2:

select * from t3 where id in (10,8,5) for update;

锁等待中……

其实这个时候id=10这条记录没有被锁住的，但id=5的记录已经被锁住了，锁的等待在id=8的这里

不信请看

Session3:

mysql> select * from t3 where id=5 for update;

锁等待中

Session4:

mysql> select * from t3 where id=10 for update;

+----+--------+------+---------------------+

| id | course | name | ctime               |

+----+--------+------+---------------------+

| 10 | JB     | g    | 2016-03-10 11:45:05 |

+----+--------+------+---------------------+

row in set (0.00 sec)

在其它session中id=5是加不了锁的，但是id=10是可以加上锁的。

案例二

在开发中，经常会做这类的判断需求：根据字段值查询（有索引），如果不存在，则插入；否则更新。

以id为主键为例，目前还没有id=22的行

Session1:

select * from t3 where id=22 for update;

Empty set (0.00 sec)

session2:

select * from t3 where id=23  for update;

Empty set (0.00 sec)

Session1:

insert into t3 values(22,'ac','a',now());

锁等待中……

Session2:

insert into t3 values(23,'bc','b',now());

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

当对存在的行进行锁的时候(主键)，mysql就只有行锁。

当对未存在的行进行锁的时候(即使条件为主键)，mysql是会锁住一段范围（有gap锁）

锁住的范围为：

(无穷小或小于表中锁住id的最大值，无穷大或大于表中锁住id的最小值)

如：如果表中目前有已有的id为（11 ， 12）

那么就锁住（12，无穷大）

如果表中目前已有的id为（11 ， 30）

那么就锁住（11，30）

对于这种死锁的解决办法是：

insert into t3(xx,xx) on duplicate key update `xx`='XX';

用mysql特有的语法来解决此问题。因为insert语句对于主键来说，插入的行不管有没有存在，都会只有行锁

案例三

mysql> select * from t3 where id=9 for update;

+----+--------+------+---------------------+

| id | course | name | ctime               |

+----+--------+------+---------------------+

|  9 | JX     | f    | 2016-03-01 11:36:30 |

+----+--------+------+---------------------+

row in set (0.00 sec)

Session2:

mysql> select * from t3 where id<20 for update;

锁等待中

Session1:

mysql> insert into t3 values(7,'ae','a',now());

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

这个跟案例一其它是差不多的情况，只是session1不按常理出牌了，

Session2在等待Session1的id=9的锁，session2又持了1到8的锁（注意9到19的范围并没有被session2锁住），最后，session1在插入新行时又得等待session2,故死锁发生了。

这种一般是在业务需求中基本不会出现，因为你锁住了id=9，却又想插入id=7的行，这就有点跳了，当然肯定也有解决的方法，那就是重理业务需求，避免这样的写法。

案例四

一般的情况，两个session分别通过一个sql持有一把锁，然后互相访问对方加锁的数据产生死锁。

案例五

两个单条的sql语句涉及到的加锁数据相同，但是加锁顺序不同，导致了死锁。

 死锁场景如下：

表结构：

CREATE TABLE dltask (

id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘auto id’,

a varchar(30) NOT NULL COMMENT ‘uniq.a’,

b varchar(30) NOT NULL COMMENT ‘uniq.b’,

c varchar(30) NOT NULL COMMENT ‘uniq.c’,

x varchar(30) NOT NULL COMMENT ‘data’,

PRIMARY KEY (id),

UNIQUE KEY uniq_a_b_c (a, b, c)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’deadlock test’;

a，b，c三列，组合成一个唯一索引，主键索引为id列。

事务隔离级别：

RR (Repeatable Read)

每个事务只有一条SQL：

delete from dltask where a=? and b=? and c=?;

SQL的执行计划：

死锁日志：

众所周知，InnoDB上删除一条记录，并不是真正意义上的物理删除，而是将记录标识为删除状态。(注：这些标识为删除状态的记录，后续会由后台的Purge操作进行回收，物理删除。但是，删除状态的记录会在索引中存放一段时间。) 在RR隔离级别下，唯一索引上满足查询条件，但是却是删除记录，如何加锁？InnoDB在此处的处理策略与前两种策略均不相同，或者说是前两种策略的组合：对于满足条件的删除记录，InnoDB会在记录上加next key lock X(对记录本身加X锁，同时锁住记录前的GAP，防止新的满足条件的记录插入。) Unique查询，三种情况，对应三种加锁策略，总结如下：

此处，我们看到了next key锁，是否很眼熟？对了，前面死锁中事务1，事务2处于等待状态的锁，均为next key锁。明白了这三个加锁策略，其实构造一定的并发场景，死锁的原因已经呼之欲出。但是，还有一个前提策略需要介绍，那就是InnoDB内部采用的死锁预防策略。

找到满足条件的记录，并且记录有效，则对记录加X锁，No Gap锁(lock_mode X locks rec but not gap)；

找到满足条件的记录，但是记录无效(标识为删除的记录)，则对记录加next key锁(同时锁住记录本身，以及记录之前的Gap：lock_mode X);

未找到满足条件的记录，则对第一个不满足条件的记录加Gap锁，保证没有满足条件的记录插入(locks gap before rec)；

死锁预防策略

InnoDB引擎内部(或者说是所有的数据库内部)，有多种锁类型：事务锁(行锁、表锁)，Mutex(保护内部的共享变量操作)、RWLock(又称之为Latch，保护内部的页面读取与修改)。

InnoDB每个页面为16K，读取一个页面时，需要对页面加S锁，更新一个页面时，需要对页面加上X锁。任何情况下，操作一个页面，都会对页面加锁，页面锁加上之后，页面内存储的索引记录才不会被并发修改。

因此，为了修改一条记录，InnoDB内部如何处理：

根据给定的查询条件，找到对应的记录所在页面；

对页面加上X锁(RWLock)，然后在页面内寻找满足条件的记录；

在持有页面锁的情况下，对满足条件的记录加事务锁(行锁：根据记录是否满足查询条件，记录是否已经被删除，分别对应于上面提到的3种加锁策略之一)；

死锁预防策略：相对于事务锁，页面锁是一个短期持有的锁，而事务锁(行锁、表锁)是长期持有的锁。因此，为了防止页面锁与事务锁之间产生死锁。InnoDB做了死锁预防的策略：持有事务锁(行锁、表锁)，可以等待获取页面锁；但反之，持有页面锁，不能等待持有事务锁。

根据死锁预防策略，在持有页面锁，加行锁的时候，如果行锁需要等待。则释放页面锁，然后等待行锁。此时，行锁获取没有任何锁保护，因此加上行锁之后，记录可能已经被并发修改。因此，此时要重新加回页面锁，重新判断记录的状态，重新在页面锁的保护下，对记录加锁。如果此时记录未被并发修改，那么第二次加锁能够很快完成，因为已经持有了相同模式的锁。但是，如果记录已经被并发修改，那么，就有可能导致本文前面提到的死锁问题。

以上的InnoDB死锁预防处理逻辑，对应的函数，是row0sel.c::row_search_for_mysql()。感兴趣的朋友，可以跟踪调试下这个函数的处理流程，很复杂，但是集中了InnoDB的精髓。

剖析死锁的成因

做了这么多铺垫，有了Delete操作的3种加锁逻辑、InnoDB的死锁预防策略等准备知识之后，再回过头来分析本文最初提到的死锁问题，就会手到拈来，事半而功倍。

首先，假设dltask中只有一条记录：(1, ‘a’, ‘b’, ‘c’, ‘data’)。三个并发事务，同时执行以下的这条SQL：

delete from dltask where a=’a’ and b=’b’ and c=’c’;

并且产生了以下的并发执行逻辑，就会产生死锁：

上面分析的这个并发流程，完整展现了死锁日志中的死锁产生的原因。其实，根据事务1步骤6，与事务0步骤3/4之间的顺序不同，死锁日志中还有可能产生另外一种情况，那就是事务1等待的锁模式为记录上的X锁 + No Gap锁(lock_mode X locks rec but not gap waiting)。这第二种情况，也是”润洁”同学给出的死锁用例中，使用MySQL 5.6.15版本测试出来的死锁产生的原因。

此类死锁，产生的几个前提：

Delete操作，针对的是唯一索引上的等值查询的删除；(范围下的删除，也会产生死锁，但是死锁的场景，跟本文分析的场景，有所不同)

至少有3个(或以上)的并发删除操作；

并发删除操作，有可能删除到同一条记录，并且保证删除的记录一定存在；

事务的隔离级别设置为Repeatable Read，同时未设置innodb_locks_unsafe_for_binlog参数(此参数默认为FALSE)；(Read Committed隔离级别，由于不会加Gap锁，不会有next key，因此也不会产生死锁)

使用的是InnoDB存储引擎；(废话！MyISAM引擎根本就没有行锁)

38. 进程所占的虚拟内存和物理内存是什么样的

你的程序运行在一个线程中，而线程运行在java虚拟机中，虚拟机内存又是由内存来，所以，内存 > 虚拟机内存 > 每个线程所开辟的内存。

1、物理内存是指由于安装内存条而获得的临时储存空间。主要作用是在计算机运行时为操作系统和各种程序提供临时储存。常见的物理内存规格有256M、512M、1G、2G等，当物理内存不足时，可以用虚拟内存代替。

2、虚拟内存是计算机系统内存管理的一种技术。它使得应用程序认为它拥有连续可用的内存（一个连续完整的地址空间），它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。

扩展资料

虚拟内存工作原理：

1、虚拟内存中央处理器访问主存的逻辑地址分解成组号a和组内地址b，并对组号a进行地址变换，即将逻辑组号a作为索引，查地址变换表，以确定该组信息是否存放在主存内。

2、虚拟内存基于对地址空间的重定义的，即把地址空间定义为“连续的虚拟内存地址”，以借此“欺骗”程序，使它们以为自己正在使用一大块的“连续”地址。

39.jvm进程所占用的虚存大于了虚拟机的堆栈设置参数，为什么不报错

  1. 首先要搞清楚JVM的内存机制： 
    JVM内存区域总体分两类，heap区 和 非heap 区(本地内存) 。 
    - heap区： 堆区分为Young Gen(新生代)，Tenured Gen（老年代-养老区）。其中新生代又分为Eden Space（伊甸园）、Survivor Space(幸存者区)。 
    - 非heap区： Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。

    首先JVM本身是一个应用程序，一般是通过C、C++实现的，这个应用程序要正常运行，是一定要向操作系统申请内存的，维持这个进程正常运行的内存，即可以理解成本地内存。

    其次，Java程序在运行过程中，会new出很多对象，这些对象又是保存在JVM的堆内存中的，Java程序在执行过程中，会加载很多类，这些类也是保存在堆内存中。

    JVM本身要对堆内存进行维护和管理，还负责垃圾回收，这些也同时会消耗本地内存，JVM在启动过程中，会依赖一些动态库，这同样也消耗本地内存。

    JAVA_OPTS='-Xms3096m -Xmx3096m -Dsun.net.inetaddr.ttl=180' 这个只是用于设置堆内存的大小，而JVM运行过程中到底会向操作系统申请多少内存，这个是由JVM在运行过程中动态决定的，我们无法设置

40. Mysql怎么保证一致性的？

这个问题分为两个层面来说。

从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性。也就是说ACID四大特性之中，C(一致性)是目的，A(原子性)、I(隔离性)、D(持久性)是手段，是为了保证一致性，数据库提供的手段。数据库必须要实现AID三大特性，才有可能实现一致性。例如，原子性无法保证，显然一致性也无法保证。

但是，如果你在事务里故意写出违反约束的代码，一致性还是无法保证的。例如，你在转账的例子中，你的代码里故意不给B账户加钱，那一致性还是无法保证。

因此，还必须从应用层角度考虑。

从应用层面，通过代码判断数据库数据是否有效，然后决定回滚还是提交数据！

41.Mysql怎么保证原子性的？

是利用Innodb的undo log。

undo log名为回滚日志，是实现原子性的关键，当事务回滚时能够撤销所有已经成功执行的sql语句，他需要记录你要回滚的相应日志信息。

例如

(1)当你delete一条数据的时候，就需要记录这条数据的信息，回滚的时候，insert这条旧数据

(2)当你update一条数据的时候，就需要记录之前的旧值，回滚的时候，根据旧值执行update操作

(3)当年insert一条数据的时候，就需要这条记录的主键，回滚的时候，根据主键执行delete操作

undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

ps:具体的undo log日志长啥样，这个可以写一篇文章了。而且写出来，看的人也不多，姑且先这么简单的理解吧。

42. Mysql怎么保证持久性的？

是利用Innodb的redo log。

正如之前说的，Mysql是先把磁盘上的数据加载到内存中，在内存中对数据进行修改，再刷回磁盘上。如果此时突然宕机，内存中的数据就会丢失。

怎么解决这个问题？

简单啊，事务提交前直接把数据写入磁盘就行啊。

这么做有什么问题？

只修改一个页面里的一个字节，就要将整个页面刷入磁盘，太浪费资源了。毕竟一个页面16kb大小，你只改其中一点点东西，就要将16kb的内容刷入磁盘，听着也不合理。

毕竟一个事务里的SQL可能牵涉到多个数据页的修改，而这些数据页可能不是相邻的，也就是属于随机IO。显然操作随机IO，速度会比较慢。

于是，决定采用redo log解决上面的问题。当做数据修改的时候，不仅在内存中操作，还会在redo log中记录这次操作。当事务提交的时候，会将redo log日志进行刷盘(redo log一部分在内存中，一部分在磁盘上)。当数据库宕机重启的时候，会将redo log中的内容恢复到数据库中，再根据undo log和binlog内容决定回滚数据还是提交数据。

采用redo log的好处？

其实好处就是将redo log进行刷盘比对数据页刷盘效率高，具体表现如下

redo log体积小，毕竟只记录了哪一页修改了啥，因此体积小，刷盘快。

redo log是一直往末尾进行追加，属于顺序IO。效率显然比随机IO来的快。

ps:不想具体去谈redo log具体长什么样，因为内容太多了。

43. Mysql怎么保证隔离性的？

利用的是锁和MVCC机制。还是拿转账例子来说明，有一个账户表如下

表名t_balance

id

user_id

balance

1

A

200

2

B

0

其中id是主键，user_id为账户名，balance为余额。还是以转账两次为例，如下图所示

至于MVCC,即多版本并发控制(Multi Version Concurrency Control),一个行记录数据有多个版本对快照数据，这些快照数据在undo log中。

如果一个事务读取的行正在做DELELE或者UPDATE操作，读取操作不会等行上的锁释放，而是读取该行的快照版本。

由于MVCC机制在可重复读(Repeateable Read)和读已提交(Read Commited)的MVCC表现形式不同，就不赘述了。

但是有一点说明一下，在事务隔离级别为读已提交(Read Commited)时，一个事务能够读到另一个事务已经提交的数据，是不满足隔离性的。但是当事务隔离级别为可重复读(Repeateable Read)中，是满足隔离性的。

44. Mysql中的MVCC策略

什么是MVCC?

英文全称为Multi-Version Concurrency Control,翻译为中文即 多版本并发控制。在小编看来，他无非就是乐观锁的一种实现方式。在Java编程中，如果把乐观锁看成一个接口，MVCC便是这个接口的一个实现类而已。

特点

1.MVCC其实广泛应用于数据库技术，像Oracle,PostgreSQL等也引入了该技术，即适用范围广

2.MVCC并没有简单的使用数据库的行锁，而是使用了行级锁，row_level_lock,而非InnoDB中的innodb_row_lock.

基本原理

MVCC的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。

基本特征

  • 每行数据都存在一个版本，每次数据更新时都更新该版本。
  • 修改时Copy出当前版本随意修改，各个事务之间无干扰。
  • 保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）

InnoDB存储引擎MVCC的实现策略

在每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为空，其实还有一列称为回滚指针，用于事务回滚，不在本文范畴）。这里的版本号并不是实际的时间值，而是系统版本号。每开始新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。

每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较来达到数据版本控制的目的。

MVCC下InnoDB的增删查改是怎么work的

1.插入数据（insert）:记录的版本号即当前事务的版本号

执行一条数据语句：insert into testmvcc values(1,"test");

假设事务id为1，那么插入后的数据行如下：

 

2、在更新操作的时候，采用的是先标记旧的那行记录为已删除，并且删除版本号是事务版本号，然后插入一行新的记录的方式。

比如，针对上面那行记录，事务Id为2 要把name字段更新

update table set name= 'new_value' where id=1;

 

3、删除操作的时候，就把事务版本号作为删除版本号。比如

delete from table where id=1;

 

4、查询操作：

从上面的描述可以看到，在查询时要符合以下两个条件的记录才能被事务查询出来：

1) 删除版本号未指定或者大于当前事务版本号，即查询事务开启后确保读取的行未被删除。(即上述事务id为2的事务查询时，依然能读取到事务id为3所删除的数据行)

2) 创建版本号 小于或者等于 当前事务版本号 ，就是说记录创建是在当前事务中（等于的情况）或者在当前事务启动之前的其他事物进行的insert。

（即事务id为2的事务只能读取到create version<=2的已提交的事务的数据集）

补充：

1.MVCC手段只适用于Msyql隔离级别中的读已提交（Read committed）和可重复读（Repeatable Read）.

2.Read uncimmitted由于存在脏读，即能读到未提交事务的数据行，所以不适用MVCC.

原因是MVCC的创建版本和删除版本只要在事务提交后才会产生。

3.串行化由于是会对所涉及到的表加锁，并非行锁，自然也就不存在行的版本控制问题。

4.通过以上总结，可知，MVCC主要作用于事务性的，有行锁控制的数据库模型。

关于Mysql中MVCC的总结

客观上，我们认为他就是乐观锁的一整实现方式，就是每行都有版本号，保存时根据版本号决定是否成功。

但由于Mysql的写操作会加排他锁（前文有讲），如果锁定了还算不算是MVCC？

了解乐观锁的小伙伴们，都知道其主要依靠版本控制，即消除锁定，二者相互矛盾，so从某种意义上来说，Mysql的MVCC并非真正的MVCC，他只是借用MVCC的名号实现了读的非阻塞而已。

 

45.mysql分表的3种方法

一，先说一下为什么要分表

当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。

根据个人经验，mysql执行一个sql的过程如下：

1,接收到sql;2,把sql放到排队队列中 ;3,执行sql;4,返回执行结果。在这个执行过程中最花时间在什么地方呢？第一，是排队等待的时间，第二，sql的执行时间。其实这二个是一回事，等待的同时，肯定有sql在执行。所以我们要缩短sql的执行时间。

mysql中有一种机制是表锁定和行锁定，为什么要出现这种机制，是为了保证数据的完整性，我举个例子来说吧，如果有二个sql都要修改同一张表的同一条数据，这个时候怎么办呢，是不是二个sql都可以同时修改这条数据呢？很显然mysql对这种情况的处理是，一种是表锁定（myisam存储引擎），一个是行锁定（innodb存储引擎）。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。如果数据太多，一次执行的时间太长，等待的时间就越长，这也是我们为什么要分表的原因。

二，分表

1，做mysql集群，

例如：利用mysql cluster ，mysql proxy，mysql replication，drdb等等

有人会问mysql集群，根分表有什么关系吗？虽然它不是实际意义上的分表，但是它启到了分表的作用，做集群的意义是什么呢？为一个数据库减轻负担，说白了就是减少sql排队队列中的sql的数量，举个例子：有10个sql请求，如果放在一个数据库服务器的排队队列中，他要等很长时间，如果把这10个sql请求，分配到5个数据库服务器的排队队列中，一个数据库服务器的队列中只有2个，这样等待时间是不是大大的缩短了呢？这已经很明显了。所以我把它列到了分表的范围以内，我做过一些mysql的集群：

linux mysql proxy 的安装，配置，以及读写分离

mysql replication 互为主从的安装及配置，以及数据同步

优点：扩展性好，没有多个分表后的复杂操作（php代码）

缺点：单个表的数据量还是没有变，一次操作所花的时间还是那么多，硬件开销大。

2，预先估计会出现大数据量并且访问频繁的表，将其分为若干个表

这种预估大差不差的，论坛里面发表帖子的表，时间长了这张表肯定很大，几十万，几百万都有可能。 聊天室里面信息表，几十个人在一起一聊一个晚上，时间长了，这张表的数据肯定很大。像这样的情况很多。所以这种能预估出来的大数据量表，我们就事先分出个N个表，这个N是多少，根据实际情况而定。以聊天信息表为例：

我事先建100个这样的表，message_00,message_01,message_02..........message_98,message_99.然后根据用户的ID来判断这个用户的聊天信息放到哪张表里面，你可以用hash的方式来获得，可以用求余的方式来获得，方法很多，各人想各人的吧。下面用hash的方法来获得表名：

  1. <?php
  2. function get_hash_table($table,$userid) {
  3. $str = crc32($userid);
  4. if($str<0){
  5. $hash = "0".substr(abs($str), 0, 1);
  6. }else{
  7. $hash = substr($str, 0, 2);
  8. }
  9. return $table."_".$hash;
  10. }
  11. echo get_hash_table('message','user18991');     //结果为message_10
  12. echo get_hash_table('message','user34523');    //结果为message_13
  13. ?>

说明一下，上面的这个方法，告诉我们user18991这个用户的消息都记录在message_10这张表里，user34523这个用户的消息都记录在message_13这张表里，读取的时候，只要从各自的表中读取就行了。

优点：避免一张表出现几百万条数据，缩短了一条sql的执行时间

缺点：当一种规则确定时，打破这条规则会很麻烦，上面的例子中我用的hash算法是crc32，如果我现在不想用这个算法了，改用md5后，会使同一个用户的消息被存储到不同的表中，这样数据乱套了。扩展性很差。

3，利用merge存储引擎来实现分表

我觉得这种方法比较适合，那些没有事先考虑，而已经出现了得，数据查询慢的情况。这个时候如果要把已有的大数据量表分开比较痛苦，最痛苦的事就是改代码，因为程序里面的sql语句已经写好了，现在一张表要分成几十张表，甚至上百张表，这样sql语句是不是要重写呢？举个例子，我很喜欢举子

mysql>show engines;的时候你会发现mrg_myisam其实就是merge。

  1. mysql> CREATE TABLE IF NOT EXISTS `user1` (
  2. ->   `id` int(11) NOT NULL AUTO_INCREMENT,
  3. ->   `name` varchar(50) DEFAULT NULL,
  4. ->   `sex` int(1) NOT NULL DEFAULT '0',
  5. ->   PRIMARY KEY (`id`)
  6. -> ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
  7. Query OK, 0 rows affected (0.05 sec)
  8. mysql> CREATE TABLE IF NOT EXISTS `user2` (
  9. ->   `id` int(11) NOT NULL AUTO_INCREMENT,
  10. ->   `name` varchar(50) DEFAULT NULL,
  11. ->   `sex` int(1) NOT NULL DEFAULT '0',
  12. ->   PRIMARY KEY (`id`)
  13. -> ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
  14. Query OK, 0 rows affected (0.01 sec)
  15. mysql> INSERT INTO `user1` (`name`, `sex`) VALUES('张映', 0);
  16. Query OK, 1 row affected (0.00 sec)
  17. mysql> INSERT INTO `user2` (`name`, `sex`) VALUES('tank', 1);
  18. Query OK, 1 row affected (0.00 sec)
  19. mysql> CREATE TABLE IF NOT EXISTS `alluser` (
  20. ->   `id` int(11) NOT NULL AUTO_INCREMENT,
  21. ->   `name` varchar(50) DEFAULT NULL,
  22. ->   `sex` int(1) NOT NULL DEFAULT '0',
  23. ->   INDEX(id)
  24. -> ) TYPE=MERGE UNION=(user1,user2) INSERT_METHOD=LAST AUTO_INCREMENT=1 ;
  25. Query OK, 0 rows affected, 1 warning (0.00 sec)
  26. mysql> select id,name,sex from alluser;
  27. +----+--------+-----+
  28. | id | name   | sex |
  29. +----+--------+-----+
  30. |  1 | 张映 |   0 |
  31. |  1 | tank   |   1 |
  32. +----+--------+-----+
  33. 2 rows in set (0.00 sec)
  34. mysql> INSERT INTO `alluser` (`name`, `sex`) VALUES('tank2', 0);
  35. Query OK, 1 row affected (0.00 sec)
  36. mysql> select id,name,sex from user2
  37. -> ;
  38. +----+-------+-----+
  39. | id | name  | sex |
  40. +----+-------+-----+
  41. |  1 | tank  |   1 |
  42. |  2 | tank2 |   0 |
  43. +----+-------+-----+
  44. 2 rows in set (0.00 sec)

从上面的操作中，我不知道你有没有发现点什么？假如我有一张用户表user，有50W条数据，现在要拆成二张表user1和user2，每张表25W条数据，

INSERT INTO user1(user1.id,user1.name,user1.sex)SELECT (user.id,user.name,user.sex)FROM user where user.id <= 250000

INSERT INTO user2(user2.id,user2.name,user2.sex)SELECT (user.id,user.name,user.sex)FROM user where user.id > 250000

这样我就成功的将一张user表，分成了二个表，这个时候有一个问题，代码中的sql语句怎么办，以前是一张表，现在变成二张表了，代码改动很大，这样给程序员带来了很大的工作量，有没有好的办法解决这一点呢？办法是把以前的user表备份一下，然后删除掉，上面的操作中我建立了一个alluser表，只把这个alluser表的表名改成user就行了。但是，不是所有的mysql操作都能用的

a，如果你使用 alter table 来把 merge 表变为其它表类型，到底层表的映射就被丢失了。取而代之的，来自底层 myisam 表的行被复制到已更换的表中，该表随后被指定新类型。

b，网上看到一些说replace不起作用，我试了一下可以起作用的。晕一个先

  1. mysql> UPDATE alluser SET sex=REPLACE(sex, 0, 1) where id=2;
  2. Query OK, 1 row affected (0.00 sec)
  3. Rows matched: 1  Changed: 1  Warnings: 0
  4. mysql> select * from alluser;
  5. +----+--------+-----+
  6. | id | name   | sex |
  7. +----+--------+-----+
  8. |  1 | 张映 |   0 |
  9. |  1 | tank   |   1 |
  10. |  2 | tank2  |   1 |
  11. +----+--------+-----+
  12. 3 rows in set (0.00 sec)

c，一个 merge 表不能在整个表上维持 unique 约束。当你执行一个 insert，数据进入第一个或者最后一个 myisam 表（取决于 insert_method 选项的值）。mysql 确保唯一键值在那个 myisam 表里保持唯一，但不是跨集合里所有的表。

d,当你创建一个 merge 表之时，没有检查去确保底层表的存在以及有相同的机构。当 merge 表被使用之时，mysql 检查每个被映射的表的记录长度是否相等，但这并不十分可靠。如果你从不相似的 myisam 表创建一个 merge 表，你非常有可能撞见奇怪的问题。

好困睡觉了，c和d在网上看到的，没有测试，大家试一下吧。

优点：扩展性好，并且程序代码改动的不是很大

缺点：这种方法的效果比第二种要差一点

三，总结一下

上面提到的三种方法，我实际做过二种，第一种和第二种。第三种没有做过，所以说的细一点。哈哈。做什么事都有一个度，超过个度就过变得很差，不能一味的做数据库服务器集群，硬件是要花钱买的，也不要一味的分表，分出来1000表，mysql的存储归根到底还以文件的形势存在硬盘上面，一张表对应三个文件，1000个分表就是对应3000个文件，这样检索起来也会变的很慢。我的建议是

方法1和方法2结合的方式来进行分表

方法1和方法3结合的方式来进行分表

我的二个建议适合不同的情况，根据个人情况而定，我觉得会有很多人选择方法1和方法3结合的方式、

46. Mysql分表和分区的区别、分库分表介绍与区别

分表与分区：

一,什么是mysql分表，分区 

什么是分表，从表面意思上看呢，就是把一张表分成N多个小表。

什么是分区，分区呢就是把一张表的数据分成N多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上，具体请参考mysql分区功能详细介绍，以及实例

二, mysql分表和分区有什么区别呢 

1.实现方式上 

mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完正的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构文件。

简 单说明一下，上面的分表呢是利用了merge存储引擎（分表的一种），alluser是总表，下面有二个分表，user1，user2。他们二个都是独立 的表，取数据的时候，我们可以通过总表来取。这里总表是没有.MYD,.MYI这二个文件的，也就是说，总表他不是一张表，没有数据，数据都放在分表里面。我们来看看.MRG到底是什么东西

alluser.MRG里面就存了一些分表的关系，以及插入数据的方式。可以把总表理解成一个外壳，或者是联接池。

分区不一样，一张大表进行分区后，他还是一张表，不会变成二张表，但是他存放数据的区块变多了。

2.数据处理上 

a），分表后，数据都是存放在分表里，总表只是一个外壳，存取数据发生在一个一个的分表里面。看下面的例子： 
select * from alluser where id='12'表面上看，是对表alluser进行操作的，其实不是的。是对alluser里面的分表进行了操作。 
b），分区呢，不存在分表的概念，分区只不过把存放数据的文件分成了许多小块，分区后的表呢，还是一张表。数据处理还是由自己来完成。

3.提高性能上

a）， 分表后，单表的并发能力提高了，磁盘I/O性能也提高了。并发能力为什么提高了呢，因为查寻一次所花的时间变短了，如果出现高并发的话，总表可以根据不同 的查询，将并发压力分到不同的小表里面。磁盘I/O性能怎么搞高了呢，本来一个非常大的.MYD文件现在也分摊到各个小表的.MYD中去了。 
b），mysql提出了分区的概念，我觉得就想突破磁盘I/O瓶颈，想提高磁盘的读写能力，来增加mysql性能。 
在这一点上，分区和分表的测重点不同，分表重点是存取数据时，如何提高mysql并发能力上；而分区呢，如何突破磁盘的读写能力，从而达到提高mysql性能的目的。

4.实现的难易度上 

a），分表的方法有很多，用merge来分表，是最简单的一种方式。这种方式根分区难易度差不多，并且对程序代码来说可以做到透明的。如果是用其他分表方式就比分区麻烦了。

b），分区实现是比较简单的，建立分区表，根建平常的表没什么区别，并且对开代码端来说是透明的。

三，mysql分表和分区有什么联系呢

1，都能提高mysql的性高，在高并发状态下都有一个良好的表面。

2，分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式（如果merge这种分表方式，不能和分区配合的话，可以用其他的分表试），访问量不大，但是表数据很多的表，我们可以采取分区的方式等。

分库与分表：

1 基本思想之什么是分库分表？

从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。

2 基本思想之为什么要分库分表？

数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈,。

3 分库分表的实施策略。

如果你的单机性能很低了，那可以尝试分库。分库，业务透明，在物理实现上分成多个服务器，不同的分库在不同服务器上。分区可以把表分到不同的硬盘上，但不能分配到不同服务器上。一台机器的性能是有限制的，用分库可以解决单台服务器性能不够，或者成本过高问题。

当分区之后，表还是很大，处理不过来，这时候可以用分库。

orderid,userid,ordertime,.....

userid%4=0，用分库1

userid%4=1，用分库2

userid%4=2, 用分库3

userid%4=3，用分库4

上面这个就是一个简单的分库路由，根据userid选择分库，即不同的服务器

3.1 何谓垂直切分

垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。

如userid,name,addr一个表，为了防止表过大，分成2个表。

userid,name

userid,addr

3.2 何谓水平切分

水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列、按性别、按省，进行划分，然后存储到多个结构相同的表，和不同的库上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，然后将这些表按照一定的规则存储到多个userDB上。

3.3垂直切分与水平切分的选择

应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。

如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。

而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。

在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。

4 分库分表存在的问题。

4.1 事务问题。

在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

4.2 跨库跨表的join问题。

在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

4.3 额外的数据管理负担和数据运算压力。

额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

47. session，cookie和token究竟是什么

http是一个无状态协议

什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速。坏处是假如我们想要把www.zhihu.com/login.html和www.zhihu.com/index.html关联起来，必须使用某些手段和工具

cookie和session

由于http的无状态性，为了使某个域名下的所有网页能够共享某些数据，session和cookie出现了。客户端访问服务器的流程如下

  • 首先，客户端会发送一个http请求到服务器端。
  • 服务器端接受客户端请求后，建立一个session，并发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。该头部包含了sessionId。Set-Cookie格式如下，具体请看Cookie详解
    Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
  • 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie
  • 服务器接收请求，分解cookie，验证信息，核对成功后返回response给客户端

注意

  • cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在url中
  • 现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用
  • 用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用cookie，数据量大的时候客户端是没有那么多空间的。
  • 如果只用cookie不用session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大

小结

简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证

token

token 也称作令牌，由uid+time+sign[+固定参数]
token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。

组成

  • uid: 用户唯一身份标识
  • time: 当前时间的时间戳
  • sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
  • 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

存放

token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中

token认证流程

token 的认证流程与cookie很相似

  • 用户登录，成功后服务器返回Token给客户端。
  • 客户端收到数据后保存在客户端
  • 客户端再次访问服务器，将token放入headers中
  • 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

token可以抵抗csrf，cookie+session不行

假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

分布式情况下的session和token

我们已经知道session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。

  • 负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。当今的几种解决session负载均衡的方法。

而token是无状态的，token字符串里就保存了所有的用户信息

  • 客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

总结

  • session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie
  • cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
  • token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
  • jwt只是一个跨域认证的方案

48. token 防止csrf

当前防御 CSRF 的几种策略

验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。
这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。
然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。
即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。

在请求地址中添加 token 并验证

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

49. 内存泄漏和内存溢出的区别和联系

1、内存泄漏memory leak :

内存泄漏是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。

2、内存溢出 out of memory :

内存溢出指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出。

3、二者的关系

内存泄漏的堆积最终会导致内存溢出

内存溢出就是你要的内存空间超过了系统实际分配给你的空间，此时系统相当于没法满足你的需求，就会报内存溢出的错误。

内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子，你存完东西之后把柜子锁上之后，把钥匙丢了或者没有将钥匙还回去，那么结果就是这个柜子将无法供给任何人使用，也无法被垃圾回收器回收，因为找不到他的任何信息。

内存溢出：一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出。比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出。说白了就是我承受不了那么多，那我就报错，

4、内存泄漏的分类（按发生方式来分类）

常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。

偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。

隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

5、内存溢出的原因及解决方法：

内存溢出原因：

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；

2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

3.代码中存在死循环或循环产生过多重复的对象实体；

4.使用的第三方软件中的BUG；

5.启动参数内存值设定的过小

内存溢出的解决方案：

第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)

第二步，检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。

第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。

重点排查以下几点：

1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

2.检查代码中是否有死循环或递归调用。

3.检查是否有大循环重复产生新对象实体。

4.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

5.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

第四步，使用内存查看工具动态查看内存使用情况

6.Java内存泄露引起原因 

内存泄露是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄露。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。那么，Java内存泄露根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。具体主要有如下几大类

1、静态集合类引起内存泄露(static 对象是不会被GC回收的)：

集合类，如HashMap、Set、ArrayList、Vector等它们是内存泄漏的常见位置。如将他们声明为static，那么它将拥有和主程序一样的生命周期，如果他们里面放置了大量对象（引用的关系），当这些对象不在使用时，因为HashMap，集合等是全局的static类型，那么垃圾回收将无法处理这些不在使用的对象，从而造成了内存泄漏。

public class MemoryLeak{

static List<Student> list = new ArrayList<Student>();

public static void main(String[] args) throws InterruptedException{

for(int i =0;i<1000000;i++){

Student stu = new Student();

list.add(stu);    //内存泄漏，无法回收

}

//便于观察虚拟机运行情况

while(true){

Thread.sleep(20000);

}

}

}

class Student{

}

2、当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。

public class MemoryLeak2 {

public static void main(String[] args) {

Set<Person> set = new HashSet<Person>();

Person p1 = new Person("唐僧","pwd1",25);

Person p2 = new Person("孙悟空","pwd2",26);

Person p3 = new Person("猪八戒","pwd3",27);

set.add(p1);

set.add(p2);

set.add(p3);//现在set里面有3个对象!

p3.setAge(2); //修改p3的年龄,此时p3的hashcode改变

set.remove(p3); //此时remove不掉，造成内存泄漏

set.add(p3); //重新添加，成功，现在set里面有4个对象

}

}

class Person{

public Person(){}

public Person(String name,String pwd,Integer age){

...

}

3、各种连接

比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。

4、单例模式

如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露，考虑下面的例子：

class A{

public A(){

B.getInstance().setA(this);

}

....

}

//B类采用单例模式

class B{

private A a;

private static B instance=new B();

public B(){}

public static B getInstance(){

return instance;

}

public void setA(A a){

this.a=a;

}

//getter...

}

5、读取流没有关闭

开发中经常忘记关闭流，这样会导致内存泄漏。因为每个流在操作系统层面都对应了打开的文件句柄，流没有关闭，会导致操作系统的文件句柄一直处于打开状态，而jvm会消耗内存来跟踪操作系统打开的文件句柄。

6、监听器

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

7、String的intern方法

在大字符串上调用String.intern() 方法，intern()会将String放在jvm的内存池中（PermGen ），而jvm的内存池是不会被gc的。因此如果大字符串调用intern()方法后，会产生大量的无法gc的内存，导致内存泄漏。如果必须要使用大字符串的intern方法，应该通过-XX:MaxPermSize参数调整PermGen内存的大小(关于设置虚拟机内存大小后续会继续发布相关博客)。

8、 将没有实现hashCode()和equals()方法的对象加入到HashSet中

这是一个简单却很常见的场景。正常情况下Set会过滤重复的对象，但是如果没有hashCode() 和 equals()实现，重复对象会不断被加入到Set中，并且再也没有机会去移除。因此给类都加上hashCode() 和 equals()方法的实现是一个好的编程习惯。可以通过Lombok的@EqualsAndHashCode很方便实现这种功能。

7. 查找内存泄漏的方法

3.1 记录gc日志

通过在jvm参数中指定-verbose:gc，可以记录每次gc的详细情况，用于分析内存的使用。

3.2 进行profiling

通过Visual VM或jdk自带的Java Mission Control，进行内存分析。

3.3 代码审查

通过代码审查和静态代码检查，发现导致内存泄漏问题的错误代码。

50.到底什么是hash呢?hash碰撞？为什么HashMap的初始容量是16？

一 、到底什么是hash呢?

hash（散列、杂凑）函数，是将任意长度的数据映射到有限长度的域上。直观解释起来，就是对一串数据m进行杂糅，输出另一段固定长度的数据h，作为这段数据的特征（指纹）。

也就是说，无论数据块m有多大，其输出值h为固定长度。到底是什么原理？将m分成固定长度（如128位），依次进行hash运算，然后用不同的方法迭代即可（如前一块的hash值与后一块的hash值进行异或）。如果不够128位怎么办？用0补全或者用1补全随意，算法中约定好就可以了。

由于用途的不同，hash在数据结构中的含义和密码学中的含义并不相同，所以在这两种不同的领域里，算法的设计侧重点也不同。

预备小知识：

抗碰撞能力：对于任意两个不同的数据块，其hash值相同的可能性极小；对于一个给定的数据块，找到和它hash值相同的数据块极为困难。

抗篡改能力：对于一个数据块，哪怕只改动其一个比特位，其hash值的改动也会非常大。

在用到hash进行管理的数据结构中，比如hashmap，hash值（key）存在的目的是加速键值对的查找，key的作用是为了将元素适当地放在各个桶里，对于抗碰撞的要求没有那么高。换句话说，hash出来的key，只要保证value大致均匀的放在不同的桶里就可以了。但整个算法的set性能，直接与hash值产生的速度有关，所以这时候的hash值的产生速度就尤为重要，以JDK中的String.hashCode()方法为例：

public int hashCode() {

int h = hash;

//hash default value : 0

if (h == 0 && value.length > 0) {

//value : char storage

char val[] = value;

for (int i = 0; i < value.length; i++) {

h = 31 * h + val[i];

}

hash = h;

}

return h;

}

很简洁的一个乘加迭代运算，在不少的hash算法中，使用的是异或+加法进行迭代，速度和前者差不多。

在密码学中，hash算法的作用主要是用于消息摘要和签名，换句话说，它主要用于对整个消息的完整性进行校验。举个例子，我们登陆知乎的时候都需要输入密码，那么知乎如果明文保存这个密码，那么黑客就很容易窃取大家的密码来登陆，特别不安全。那么知乎就想到了一个方法，使用hash算法生成一个密码的签名，知乎后台只保存这个签名值。由于hash算法是不可逆的，那么黑客即便得到这个签名，也丝毫没有用处；而如果你在网站登陆界面上输入你的密码，那么知乎后台就会重新计算一下这个hash值，与网站中储存的原hash值进行比对，如果相同，证明你拥有这个账户的密码，那么就会允许你登陆。银行也是如此，银行是万万不敢保存用户密码的原文的，只会保存密码的hash值而而已。

在这些应用场景里，对于抗碰撞和抗篡改能力要求极高，对速度的要求在其次。一个设计良好的hash算法，其抗碰撞能力是很高的。以MD5为例，其输出长度为128位，设计预期碰撞概率为，这是一个极小极小的数字——而即便是在MD5被王小云教授破解之后，其碰撞概率上限也高达，也就是说，至少需要找次才能有1/2的概率来找到一个与目标文件相同的hash值。而对于两个相似的字符串，MD5加密结果如下：

MD5("version1") = "966634ebf2fc135707d6753692bf4b1e";

MD5("version2") = "2e0e95285f08a07dea17e7ee111b21c8";

可以看到仅仅一个比特位的改变，二者的MD5值就天差地别了。

二，什么是hash碰撞

如果两个输入串的hash函数的值一样，则称这两个串是一个碰撞(Collision)。既然是把任意长度的字符串变成固定长度的字符串，所以必有一个输出串对应无穷多个输入串，碰撞是必然存在的。

一个优良的hash函数 f 应当满足以下三个条件：

（1）对于任意y，寻找x，使得f(x)=y，在计算上是不可行的。

（2）给定x1∈A,找x2∈B，，使得f(x1)=f(x2)，在计算上是不可能的，这也就是弱无碰撞性。

（3）寻找x1，x2，使得f(x1)=f(x2)，在计算上也是不可行的，这也就是强无碰撞性。

这样就称为安全保密的Hash函数，除了枚举外不可能有别的更快的方法。如第3条，根据生日定理，要想找到这样的x1，x2，理论上需要大约2^(n/2)的枚举次数。

因为前两条都能被破坏的hash函数太弱而被抛弃，几乎所有的hash函数的破解，都是指的破坏上面的第3条性质，即找到一个碰撞。在密码学上还有一个概念是理论破解，指的是提出一个算法，使得可以用低于理论值得枚举次数找到碰撞。

三、碰撞处理

　　通常有两类方法处理碰撞：开放寻址(Open Addressing)法和链接(Chaining)法。前者是将所有结点均存放在散列表T[0..m-1]中；后者通常是把散列到同一槽中的所有元素放在一个链表中，而将此链表的头指针放在散列表T[0..m-1]中。

 (1)开放寻址法

　　所有的元素都在散列表中，每一个表项或包含动态集合的一个元素，或包含NIL。这种方法中散列表可能被填满，以致于不能插入任何新的元素。在开放寻址法中，当要插入一个元素时，可以连续地检查或探测散列表的各项，直到有一个空槽来放置待插入的关键字为止。有三种技术用于开放寻址法：线性探测、二次探测以及双重探测。

<1>线性探测

　　给定一个普通的散列函数h'：U —>{0，1，.....，m-1}，线性探测方法采用的散列函数为：h(k,i) = (h'(k)+i)mod m，i=0,1,....,m-1　　

探测时从i=0开始，首先探查T[h'(k)]，然后依次探测T[h'(k)+1]，…，直到T[h'(k)+m-1]，此后又循环到T[0]，T[1]，…，直到探测到T[h'(k)-1]为止。探测过程终止于三种情况：

　 (1)若当前探测的单元为空，则表示查找失败（若是插入则将key写入其中）；

　 (2)若当前探测的单元中含有key，则查找成功，但对于插入意味着失败；

　 (3)若探测到T[h'(k)-1]时仍未发现空单元也未找到key，则无论是查找还是插入均意味着失败(此时表满)。

线性探测方法较容易实现，但是存在一次群集问题，即连续被占用的槽的序列变的越来越长。采用例子进行说明线性探测过程，已知一组关键字为(26，36，41，38，44，15，68，12，6，51)，用除余法构造散列函数，初始情况如下图所示：

散列过程如下图所示：

<2>二次探测

　　二次探测法的探查序列是：h(k,i) =(h'(k)+i*i)％m ,0≤i≤m-1 。初次的探测位置为T[h'(k)]，后序的探测位置在次基础上加一个偏移量，该偏移量以二次的方式依赖于i。该方法的缺陷是不易探查到整个散列空间。

<3>双重散列

　　该方法是开放寻址的最好方法之一，因为其产生的排列具有随机选择的排列的许多特性。采用的散列函数为：h(k,i)=(h1(k)+ih2(k)) mod m。其中h1和h2为辅助散列函数。初始探测位置为T[h1(k)]，后续的探测位置在此基础上加上偏移量h2(k)模m。

 （2）链接法

　　将所有关键字为同义词的结点链接在同一个链表中。若选定的散列表长度为m，则可将散列表定义为一个由m个头指针组成的指针数组T[0..m-1]。凡是散列地址为i的结点，均插入到以T[i]为头指针的单链表中。T中各分量的初值均应为空指针。在拉链法中，装填因子α可以大于1，但一般均取α≤1。

举例说明链接法的执行过程，设有一组关键字为(26，36，41，38，44，15，68，12，6，51)，用除余法构造散列函数，初始情况如下图所示：

最终结果如下图所示：

四，为什么HashMap初始容量是2<<3?

如果两个元素不相同,但是hash函数的值相同,这两个元素就是一个碰撞

因为把任意长度的字符串变成固定长度的字符串,所以存在一个hash对应多个字符串的情况,所以碰撞必然存在

为了减少hash值的碰撞,需要实现一个尽量均匀分布的hash函数,在HashMap中通过利用key的hashcode值,来进行位运算

公式:index = e.hash & (newCap - 1)

举个例子:

1.计算"book"的hashcode

十进制 : 3029737

二进制 : 101110001110101110 1001

2.HashMap长度是默认的16，length - 1的结果

十进制 : 15

二进制 : 1111

3.把以上两个结果做与运算

101110001110101110 1001 & 1111 = 1001

1001的十进制 : 9,所以 index=9

hash算法最终得到的index结果,取决于hashcode值的最后几位

为了推断HashMap的默认长度为什么是16

现在,我们假设HashMap的长度是10,重复刚才的运算步骤:

hashcode : 101110001110101110 1001

length - 1 :                                     1001

index :                                            1001

再换一个hashcode 101110001110101110 1111 试试:

hashcode : 101110001110101110 1111

length - 1 :                                     1001

index :                                            1001

从结果可以看出,虽然hashcode变化了,但是运算的结果都是1001,也就是说,当HashMap长度为10的时候,有些index结果的出现几率

会更大而有些index结果永远不会出现(比如0111),这样就不符合hash均匀分布的原则

反观长度16或者其他2的幂,length - 1的值是所有二进制位全为1,这种情况下,index的结果等同于hashcode后几位的值

只要输入的hashcode本身分布均匀,hash算法的结果就是均匀的

所以,HashMap的默认长度为16,是为了降低hash碰撞的几率

51. 线程及与进程的对比

一、为什么要引入线程

　　进程是为了提高CPU的执行效率，减少因程序等待带来的CPU空转以及其他计算机软硬件资源而提出来的。进程是一个资源拥有者，因而在进程的创建、撤消和切换中，系统必须为之付出较大的时空开销。也正因为如此，在系统中所设置的进程数目不宜过多，进程切换的频率也不宜太高，但这也就限制了并发程度的进一步提高。如何能使多个程序更好地并发执行，同时又尽量减少系统的开销，已成为近年来设计操作系统时所追求的重要目标。于是，有不少操作系统的学者们想到，可否将进 程的上述属性分开，由操作系统分开来进行处理。即对作为调度和分派的基本单位，不同时作为独立分配资源的单位，以使之轻装运行；而对拥有资源的基本单位， 又不频繁地对之进行切换。正是在这种思想的指导下，产生了线程概念。即，为了减少进程切换和创建的开销，提高执行效率和节省资源，人们在开始操作系统中引入“线程”（thread）的概念。

二、线程

1、线程的基本概念

线程是进程的一部分，有时候也被称为轻量级进程（light weight process）。线程是进程中执行运算的最小单位，亦即执行处理机调度的基本单位。如果把进程理解为在逻辑上操作系统所完成的任务，那么线程表示完成该任务的许多可能的子任务之一。

2、引入线程的好处

（1）易于调度。

（2）提高并发性。通过线程可方便有效地实现并发性。进程可创建多个线程来执行同一程序的不同部分。

（3）开销少。创建线程比创建进程要快，所需开销很少。。

（4）利于充分发挥多处理器的功能。通过创建多线程进程（即一个进程可具有两个或更多个线程），每个线程在一个处理器上运行，从而实现应用程序的并发性，使每个处理器都得到充分运行。

3、线程的适用范围

线程可以有效地提高系统的执行效率，但并不是在所有计算机系统中都是适用的，如某些很少做进程调度和切换的实时系统。使用线程的最大好处是有多个任务需要处理机处理时，可以减少处理机的切换时间；而且，线程的创建和结束所需要的系统开销也比进程的创建和结束要小得多。最适用使用线程的系统是多处理机系统、网络系统或分布式系统。

4、线程分类与执行

线程的两个基本类型是用户级线程和内核级线程（系统级线程）。

1、用户级线程

用户级线程的管理过程全部由用户程序完成，为了对用户级线程进行管理，操作系统提供一个在用户空间执行的线程库。该线程库提供创建、调度和撤销线程功能。同时，该线程库也提供线程见的通信、线程的执行以及存储线程上下文的功能。用户级线程只使用用户堆栈和分配给所属进程的用户寄存器。

（1）用户级线程的调度算法和调度过程全部由用户自行选择和确定，与操作系统内核无关。

（2）用户级线程的调度算法只进行线程上下文切换而不进行处理机切换。

（3）因，用户级线程的上下文切换和内核无关，所以可能出现，尽管相关进程的状态是阻塞的或等待的，但所属线程的状态却是执行的

2、内核级线程

由操作形同内核进行管理。操作系统内核给应用程序提供相应地系统调用和应用程序接口，以使用户可以创建、执行和撤销线程。操作系统内核，负责进程的调度，也负责进程内不同线程的调度，故内核级线程不会出现进程处于阻塞或等待状态，而线程处于执行状态的情况。

系统开销：用户级线程<内核级进程<进程

3、执行

线程有3个基本状态：执行、就绪和阻塞。有五种基本操作：派生、阻塞、激活、调度和结束。

三、进程与线程

1、进程和线程的关系

（1）一个线程只能属于一个进程，而一个进程可以有多个线程。线程是操作系统可识别的最小执行和调度单位。一个没有线程的进程可以被看作是单线程。

（2）资源分配给进程，同一进程的所有线程共享该进程的所有资源。

2、线程与进程的区别

（1）线程的改变只代表了CPU执行过程的改变，而进程所拥有的资源都没有发生改变。或者说，除了CPU之外，计算机内的软硬件资源的分配与线程无关，线程只能共享它所属进程的资源。

（2）与进程控制表和 PCB 相似，每个线程也有自己的线程控制表 TCB ，而这个 TCB 中所保存的线程状态信息则要比 PCB 表少得多，这些信息主要是相关指针用堆栈（系统栈和用户栈），寄存器中的状态数据。

（3）进程拥有一个完整的虚拟地址空间，不依赖于线程而独立存在；反之，线程是进程的一部分，没有自己的地址空间，与进程内的其他线程一起共享分配给该进程的所有资源。

3、线程与进程对比

我们从调度、并发性、 系统开销、拥有资源等方面，来比较线程与进程。

1．调度

在传统的操作系统中，拥有资源的基本单位和独立调度、分派的基本单位都是进程。而在引入线程的操作系统中，则把线程作为调度和分派的基本单位。而把进程作为资源拥有的基本单位，使传统进程的两个属性分开，线程便能轻装运行，从而可显著地提高系统的并发程度。在同一进程中，线程的切换不会引起进程的切换，在由一个进程中的线程切换到另一个进程中的线程时，将会引起进程的切换。

2．并发性

在引入线程的操作系统中，不仅进程之间可以并发执行，而且在一个进程中的多个线程之间，亦可并发执行，因而使操作系统具有更好的并发性，从而能更有效地使 用系统资源和提高系统吞吐量。例如，在一个未引入线程的单CPU操作系统中，若仅设置一个文件服务进程，当它由于某种原因而被阻塞时，便没有其它的文件服 务进程来提供服务。在引入了线程的操作系统中，可以在一个文件服务进程中，设置多个服务线程，当第一个线程等待时，文件服务进程中的第二个线程可以继续运 行；当第二个线程阻塞时，第三个线程可以继续执行，从而显著地提高了文件服务的质量以及系统吞吐量。

3．拥有资源

不论是传统的操作系统，还是设有线程的操作系统，进程都是拥有资源的一个独立单位，它可以拥有自己的资源。一般地说，线程自己不拥有系统资源(也有一点必 不可少的资源)，但它可以访问其隶属进程的资源。亦即，一个进程的代码段、数据段以及系统资源，如已打开的文件、I/O设备等，可供问一进程的其它所有线 程共享。

4．系统开销

由于在创建或撤消进程时，系统都要为之分配或回收资源，如内存空间、I／o设备等。因此，操作系统所付出的开销将显著地大于在创建或撤消线程时的开销。类 似地，在进行进程切换时，涉及到整个当前进程CPU环境的保存以及新被调度运行的进程的CPU环境的设置。而线程切换只须保存和设置少量寄存器的内容，并 不涉及存储器管理方面的操作。可见，进程切换的开销也远大于线程切换的开销。此外，由于同一进程中的多个线程具有相同的地址空间，致使它们之间的同步和通信的实现，也变得比较容易。在有的系统中，线程的切换、同步和通信都无须

52. Java基本数据类型及所占字节大小

一、Java基本数据类型

　　基本数据类型有8种：byte、short、int、long、float、double、boolean、char

　　分为4类：整数型、浮点型、布尔型、字符型。

　　整数型：byte、short、int、long

　　浮点型：float、double

　　布尔型：boolean

　　字符型：char

 二、各数据类型所占字节大小

　　计算机的基本单位：bit .　　一个bit代表一个0或1

　　byte：1byte = 8bit　　　　 1个字节是8个bit

　　short：2byte

　　int：4byte

　　long：8byte

　　float：4byte

　　double：8byte

　　boolean：1byte

　　char：2byte

Java面试题（自己不会的查大佬的贴，持续记录中）相关推荐

  1. Java面试题及答案整理 140道（ 2021年持续更新）

    发现网上很多Java面试题都没有答案,所以花了很长时间搜集整理出来了这套Java面试题大全,希望对大家有帮助哈~ 本人发现网上虽然有不少Java相关的面试题,但第一未必全,第二未必有答案,第三虽然有答 ...

  2. 复习Java第一个项目学生信息管理系统 04（权限管理和动态挂菜单功能） python简单爬数据实例Java面试题三次握手和四次挥手生活【记录一个咸鱼大学生三个月的奋进生活】016

    记录一个咸鱼大学生三个月的奋进生活016 复习Java(学生信息管理系统04权限管理和动态挂菜单功能) 改写MainFrame的构造方法 新增LoginFrame的验证登录是否成功的代码 新增Logi ...

  3. Java面试题及答案整理（ 2022最新版，持续更新）

    发现网上很多Java面试题都没有答案,所以花了很长时间搜集整理出来了这套Java面试题大全,希望对大家有帮助哈~ Java面试永远是程序员迈向成功的第一个门槛,想要面试成功,各种面试题的洗礼是必不可少 ...

  4. 面向面试题的前端学习-js篇（自用，持续完善中）

    前言:初心是记录面试题,慢慢由每个知识点引伸出去,逐渐查缺补漏,构建出更完善的前端知识系统. 题目来源:牛客网 gitnub 目录 HTTP协议 get请求传参长度的误区 补充get和post请求在缓 ...

  5. Java面试题阶段汇总

    希望能够坚持不断的整理,做最全的Java面试题题库,帮助更多的人在面试过程中发挥出自己的实力.也希望自己能够持之以恒的做一件事情不忘初心,加油! 初级面试题 Java面试题-基础篇一 Java面试题- ...

  6. 复习JavaWeb的小项目书籍信息的增删改查分页功能实现Java面试题Session和Cookie的基础概念生活【记录一个咸鱼大学生三个月的奋进生活】034

    记录一个咸鱼大学生三个月的奋进生活034 JavaWeb的增删改查分页功能实现 前期准备工作(数据库连接类和实体类) 数据库建立 数据库连接类(DBManager) 书籍信息的实体类(Book) 操作 ...

  7. Java面试题基础系列228道（2），查漏补缺

    上一篇更新1~20题的答案解析 本次更新Java 面试题(一)的21~50题答案 21.描述一下 JVM 加载 class 文件的原理机制? JVM 中类的装载是由类加载器(ClassLoader)和 ...

  8. java 实体类包含list 怎么取值_2019 最新 500 道 Java 面试题

    2015 年,因为工作岗位的变动,开始负责给集团招聘一些技术人员,出于对公司的负责,也为了更好的胜任技术经理的职位,在面试的这件事上,我做了大量的"功课",首先我研究了几乎所有大厂 ...

  9. 用友公司Java面试题（含答案）

    为什么80%的码农都做不了架构师?>>>    用友公司Java面试题(含答案) 1.Hashtable和HashMap有什么区别?   a.Hashtable是继承自陈旧的Dict ...

最新文章

  1. 特斯拉被曝储存大量未加密个人数据 | 极客头条
  2. 关于@property()的那些属性及ARC简介【nonatomic,atomic,assign,retain,strong,weak,copy。】
  3. 统计数据库每天的数据增长量的脚本
  4. jQuery筛选器常用总结
  5. Bootstrap组件_分页
  6. ROS探索总结（十二）——坐标系统
  7. python实现kmean算法_K-means聚类算法的Python实现,Kmeans
  8. 对微软的敌视何时休？ 从一篇语言评论文章对C#的评价说起
  9. ubuntu12.04安装搜狗输入法和配置
  10. pythonturtle库画图_python 用turtle库画图
  11. 教大家防止Jar包被反编译
  12. Anaconda及TensorFlow安装
  13. APP限制录屏怎么办？如何绕过APP录屏限制和截图限制-支持安卓和IOS
  14. qt:cannot open C:\Users\某某某\AppData\Local\Temp\main.obj.15576.16.jom for write
  15. Linux 中断（IRQ/softirq）基础：原理及内核实现
  16. 3D建模贴图是个啥？先薅羊毛再说！（附1000张高清3D贴图素材）
  17. 邮箱登录入口，163邮箱个人登录入口，163邮箱注册登录
  18. CSS之背景样式及边框样式
  19. ucos操作系统（1）——OSTCBY，OSRdyGrp，OSRdyTbl
  20. Dijkstra算法（单源最短路径）

热门文章

  1. 【华为内部狂转的想象力惊人的好文】趣谈大数据
  2. Ubuntu 20.04 搜狗输入法安裝
  3. PNG图片宽高crc32爆破代码
  4. 坚叔：让科幻片的概念变成产品丨编程挑战赛 x 嘉宾分享
  5. 习惯，到底有多重要？
  6. 结构体中使用冒号对位的操作
  7. Echarts实现自定义图标——风向图
  8. Ubuntu 16.04 Wifi列表是空的(搜索不到Wifi)的解决方法
  9. 沉浸式过山车 梦幻新体验
  10. 外汇平台正规排行榜 Flyerinternational稳居前三