面试笔记：

内存泄漏memory leak :指程序在申请并使用完内存后，没有进行归还，自己无法使用，系统也无法使用，也没法被GC回收。一次内存泄漏似乎不会有太大的影响，但内存泄漏的堆积会导致内存溢出。指向这块内存空间的指针不存在了，钥匙丢了，对象不可达。在c++中需要程序猿手动释放内存对象，所以在C++中更容易存在内存泄漏，而java引入了自动回收机制，改善了这个问题。JVM会自动回收不可达的对象，但可达的无用对象(被有用对象引用着)仍不会被回收，导致内存泄漏

所有的可达性算法都会有起点，这个起点就是GC Root

通过GC Root 找出所有存活着的对象，那么剩下所有的没有标记的对象就是需要回收的对象  只回收不可达对象

GC root：JVM进行GC的时候会从GC root进行对象的可达性判断，找到活着的/可达的对象 

方法区、栈、本地方法栈不被GC所管理,因此选择这些区域内的对象作为GC roots,被GC roots引用的对象不被GC回收。栈中的局部变量（也叫局部变量表）中引用的对象+方法区中类的静态变量引用的对象+本地方法栈中 JNI (Java Native Interface  Native方法)引用的对象

内存溢出out of memory :指程序申请内存时，没有足够的内存空间供申请者使用，比如给了一块存储int类型数据的存储空间，但是却用来存储long类型的数据，结果就是内存不够用，此时就会报错OOM,即内存溢出。内存不足

内存溢出原因：

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据，如一次取十万条记录到内存。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此，对于数据库的查询尽量采用分页的方式；

2.代码中存在死循环或递归调用，循环中创建了过多重复对象实例；

3.JVM启动参数内存值设定的过小

内存溢出的解决方案：

1修改JVM启动参数，直接增加内存 -Xms，-Xmx参数

2检查错误日志，查看OOM错误前是否有其它异常或错误。

通过jdk自带的两个可视化工具/插件来定位问题 jconsole.exe   jvisualvm.exe 

Dump机制：设置启动参数-XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath 当发生OOM 的时候，会自动生成一个 .hprof (heap profile)二进制文件

再使用工具分析这个 .hprof 文件来定位问题，比如用 VisualVM 或 Memory Analyzer (MAT) ，能看到创建的实例的个数和大小，可以将错误具体定位到某行代码

具体OOM异常：

1 java.lang.OutOfMemoryError: Java heap space

new 了一个很大的对象2 OOM：GC overhead limit exceeded

GC回收时间过长，超过98%的时间用来做GC，但只回收了不到2%的堆内存

3 unable to create new native thread

一个应用进程创建了多个线程，超过系统承载极限

https://zhuanlan.zhihu.com/p/79355050

虚拟内存/物理内存

由页表记录映射位置，当访问到某个地址的时候，通过页表中的有效位，可以得知此数据是否在内存中，如果不在，则通过缺页异常，将磁盘对应的数据拷贝到内存中

mmap用来建立从虚拟空间地址到硬盘空间地址的映射，可以将一个虚拟空间地址映射到一个磁盘文件上

JVM如JRockit（Oracle）、J9（IBM）、HotSpot

方法区是JVM的规范，而永久代、元空间则是JVM规范的实现

Jdk1.8使用Metaspace代替永久代，与永久代最大的区别是：元空间使用本地内存(可以通过参数-XX:MetaspaceSize来指定元空间的大小)，永久代则在虚拟机内存中

网络：

1物理层 比特流转为电信号，在物理媒体上传输数据 IEEE802.3 802.5协议 rj-45标准 集线器、中继器、调制解调器、网线

2数据链路层：将数据封装成帧 差错控制 流量控制 在通信实体之间建立数据链路连接 网卡网桥交换机 PPP CSMA/CD

3√网络层 为数据包选择路由  路由器

IP ICMP控制信息 IGMP ARP地址解析 RIP OSPF DHCP BGP

4√传输层 端到端的通信 TCP UDP

5会话层 解除或建立连接/会话

6表示层 数据格式的转换

7√应用层 最靠近用户的一层，为用户的应用程序提供访问网络服务的接口 FTP文件传输 HTTP HTTPS加密 SMTP 电子邮件发/收POP3  DNS域名系统/域名解析Telnet远程登录

DNS域名系统(是域名和IP地址相互映射的一个分布式数据库，将域名翻译解析成ip地址， DNS 域名解析 域名www.baidu.com)

输入URL到返回页面的全过程(天龙八步)：

1根据域名，进行DNS域名解析；

2.拿到解析的IP地址，建立TCP连接；

3.向IP地址，发送HTTP请求；

4.服务器处理请求；

5.返回响应结果；

6.关闭TCP连接；

7.浏览器解析HTML视图；

8.浏览器对页面布局渲染；

HTTP：是基于TCP/IP通信协议来传递数据的网络传输协议浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送请求

无连接：服务器处理完客户的请求，并收到客户的应答后，就会断开连接，采用这种方式可以节省传输时间。

无状态：后续处理需要前面的信息，则它必须重传，这可能导致连接传送的数据量增大。但在服务器不需要先前信息时，它的应答就较快。

当客户端一次HTTP请求完成以后，客户端再发送一次请求，服务器并不知道当前客户端是一个老用户。

可以用Cookie来解决无状态的问题，客户端发起请求时，携带cookie

浏览器能显示的内容有HTML、XML、GIF、Flash 等，是通过

MIME Type 区分它们，决定用什么内容什么形式来显示

请求报文：请求行(请求方法 url)+请求头+请求体

响应报文：状态行(http版本号 状态码)+响应头+响应体

URI统一资源标识符 URI=URL定位符+URN名称

URL是URI的子集，URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式

URL格式：

协议名://ip地址或域名:端口号/资源在服务器中的路径

?name=value&name=value

tcp和udp的区别？

1、TCP是面向连接的（在客户端和服务器之间传输数据之前要先建立连接，长连接），UDP是无连接的（发送数据前不需要先建立连接）

2、TCP提供可靠的服务（通过TCP传输的数据，无差错，不丢失，不重复，且按序到达）；UDP提供面向事务的简单的不可靠的传输。

3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性比较高的通信。随着网速的提高，UDP使用越来越多。

4、TCP连接只能是点到点的，而UDP支持一对一、一对多和多对多的交互通信。

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

6、UDP程序结构更加简单，没有握手

7. TCP保证数据的顺序，UDP不能保证

无连接：如从A-B有多条路径，每个数据包可以选择不同的路径 每个数据包之间都是互相独立的，各走各的路 每个数据包到达B的顺序是不确定的  根据数据包选择的路径的长短而定 支持一对多通信

不可靠不稳定容易丢包但速度快寄信只管发不管对方有没有收到用于只要通讯速度尽量的快/实时性，比如语音和视频时

面向连接：只支持一对一通信传输的过程是可靠的，因此TCP需要经过三次握手的环节，确立连接关系之后，才可以进行传输，另外TCP还有超时重传机制、排序机制，有发送的窗口，拥塞控制机制，保证接收方接收到的就是发送方发送过去的数据打电话

对网络通讯质量有要求的时候，整个数据要准确无误的传递给对方时

面向连接三个阶段：建立连接-传输数据-释放连接

TCP三次握手：客户端C 服务器S 确认ACK 同步SYN 序列号seq

1 C向S发送一个带有SYN+随机生成的seq的请求报文段，请求建立连接，C进入SYN_SENT状态，等待服务器的确认

2 S收到后，返回一个带有SYN+ACK+随机生成的seq的确认报文段，表示C可以传输数据了，S进入SYN_RCVD状态

3 C收到后，返回一个确认应答ACK(对确认的确认)，表示收到了S的应答，准备开始传输数据，C和S都进入ESTABLISHED状态

为什么是三次握手而不是两次握手：

为了实现可靠数据传输，核心就是互相对seq的确认，三次握手的过程即是通信双方相互告知seq值，然后ack中ack=seq+1传给对方。

如果只是两次握手，就只有C的seq能被确认，S的seq得不到确认

举例：主机A发出的连接请求没有收到主机B的确认，过一段时间后，A又向B发送连接请求，连接建立成功，完成数据传输；

 但主机A之前发送的请求因网络延迟也到达了主机B(并没有丢失)，B以为是A又发起的新请求，于是B同意连接，并向主机A发回确认，如果是两次握手，则B会以为新的连接已经建立，并一直等待A发来数据。这样，B的很多资源就白白浪费掉了。采用三次握手可以防止上述现象发生，比如此时A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。就不会导致主机B的资源浪费。

如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证C与S的可靠数据传输了

SYN攻击：SYN泛洪攻击/SYN FLOOD

攻击者Client在短时间内伪造大量不存在的IP地址，向Server不断地发送SYN包，Server回复ACK确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪

解决：设置SYN cookie模块

DOS：Denial of Service拒绝服务攻击使服务器系统过于忙碌而不能执行有用的业务，并占尽系统的关键资源

DDoS分布式拒绝服务

四次挥手：

1 C发送连接释放报文段(FIN+seq)，用来关闭C到S的数据传送,C停止发送数据，客户端进入FIN-WAIT-1（终止等待1）状态

2 S发送ACK  S收到连接释放报文，发出确认报文ACK，服务端就进入了CLOSE-WAIT（关闭等待）状态，这时候处于半关闭状态，客户端已经没有数据要发送了，但是服务器若发送数据，客户端依要接收

3 S发送FIN连接释放报文段 用来关闭S到C的数据传送，S进入LAST_ACK状态

4 C发送ACK C进入TIME_WAIT状态 S进入CLOSED状态

经过2MSL（最长报文段寿命）时间后，彻底关闭连接，C进入CLOSED状态

正向代理：客户端代理, 代理客户端, 服务端不知道实际发起请求的客户端 访问原来无法访问的资源/翻墙

反向代理：服务端代理, 代理服务端, 客户端不知道实际提供服务的服务端  保证内网的安全，阻止web攻击，大型网站通常将反向代理作为公网访问地址  负载均衡

中间人攻击Man-in-the-Middle Attack, MITM如SMB会话劫持、DNS欺骗  拦截正常的网络通信数据，并进行数据篡改，而通信的双方却毫不知情

Http缓存：主要针对css，js，图片等更新频率不大的静态文件

缓存命中率:从缓存中得到数据的请求数与总请求数的比率,越高越好

过期内容：超过设置的有效时间，通常必须重新向源服务器请求新的内容或者验证过期的缓存内容是否仍然有效

验证：验证缓存中的过期内容是否仍然有效，验证通过的话刷新过期时间   失效：把失效内容从缓存中移除

请求头/响应头中的缓存字段：

Cache-Control(no-cache 不用过期的缓存)

Expires资源过期时间 由S->B  Last-Modified由S->B

if-Modified-Since由B->S 其实就是之前服务器给的Last-Modified

Http缓存主要分为两种：强缓存和协商缓存

浏览器先根据请求的http头信息来判断是否命中强缓存，如果命中则直接加载强缓存中的资源，不会将请求发送到服务器，返回200，这样加载速度最快，性能也很好。

如果未命中强缓存，则浏览器会将请求发送到服务器，服务器判断是否命中协商缓存+协商缓存是否失效(即资源是否被修改了)。若可以使用，则服务器并不会返回资源信息，浏览器从协商缓存中加载资源，返回304。

如果未命中协商缓存，则服务器会将完整的资源返回给浏览器，浏览器加载新资源，并更新缓存。

强缓存：所请求的数据在缓存数据库中尚未过期时，不与服务器进行交互，直接使用缓存中的数据

当强缓存过期，使用协商缓存的方式，向浏览器发送请求,验证请求的数据是否已经更新，如果已更新则返回新的数据，若未更新则使用缓存数据库中的缓存数据，并刷新过期时间expires

向服务器发起请求，判断自己的缓存是不是最新，如果是就接着用，不是就请求最新的文件，缓存起来用，以此循环

http缓存方案，md5缓存/cdn缓存 CDN会选择一个离用户最近的CDN边缘节点来响应用户的请求

cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用session

禁用cookie后仍想使用session，通过 url传值，把session id附加到url上

100临时响应 200成功 300重定向 400客户端错误 500服务器错误

301 本网页永久性转移到另一个地址302临时性地址移动

304浏览器中有缓存

400请求中有语法错误403请求被服务器拒绝 405请求方式错误

415 不支持的媒体格式

502 网关错误 504 网关超时 503服务不可用

Http和Https：

https=http+ssl/tls加密  TLS1.2

http端口号为80，https端口号为443

ssl加密：采用对称加密和非对称加密的混合加密方式

加密和解密同用一个密钥的方式称为共享密钥加密/对称加密

先使用对方的公钥对数据进行加密，对方再用自己的私钥解密得到数据公开密钥加密/非对称加密常见算法有RSA

混合加密：先用非对称加密方式传输一个密钥，再使用此密钥进行对称加密方式传输数据因为非对称加密方式比较慢

SSL全称为 Socket Security Layer，TLS全称为Transport Layer Security，这两者没有本质的区别，都是做的传输层之上的加密(介于传输层及应用层之间)  保证数据的保密性(所有信息都是加密传播，第三方无法窃听数据)和完整性(一旦第三方篡改了数据，接收方会知道)和身份验证(服务器配备了由CA颁发的证书，可以证明服务器的身份)

TLS握手，主要分为三个阶段：参数协商、身份验证、密钥交换

TLS算法：信息摘要  数字签名  对称加密 密钥交换算法

C和S都需要验证自己收到的公钥的正确性，而这个验证通过CA认证实现，即数字证书认证

1当TCP建立连接之后，TLS握手的第一步由客户端发起，发送 ClientHello 的消息到服务器

2 然后服务器端在收到这个 ClientHello，从中选择服务器支持的版本和套件，发送 ServerHello 消息(其中包含证书)

3 客户端收到 ServerHello 后，会对其中的证书进行验证，得到对应的公钥

4 客户端生成一个随机数X，使用公钥对其加密，传给S

5 S用私钥对其解密得到X

6 C和S以X为密钥进行对称加密通信

各种算法：RSA/DH/PSK/SRP

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户端也不记录过去的请求数据

HTTP1.1版本新特性：

1默认使用长连接/持久连接，节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求

2 B可以以管道方式pipeline，一个 TCP 连接中可以同时发出多个HTTP请求，而不用一个个等待响应，不用等待上一次请求结果返回，就可以直接发出下一次请求

3支持host域

HTTP1.0和1.1在之后很长的一段时间内会一直并存

HTTP2.0版本新特性：HTTP2源自于 SPDY协议

采用二进制格式传输数据，Frame是 HTTP2 二进制格式的基础HTTP1.x 采用文本格式

HTTP2对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量，而HTTP1.x每次请求，都会携带大量冗余头信息，浪费了很多带宽资源首部压缩

支持多路复用技术Multiplexing通过复用仅仅一条或几条TCP连接，在客户端与服务器间发送几十个请求或回应。刷新页面就不用再重新建立TCP连接和SSL连接

对请求划分优先级

Server Push技术服务端能够更快的把资源推送给客户端

最小化网络延迟，提升网络速度

浏览器可以对同一Host建立多个TCP连接

当浏览器拿到一个有几十张图片的网页，肯定不能只开一个TCP连接按顺序下载，那样用户会等很久，这时候就需要对同一个Host 建立多个 TCP 连接。

Chrome 最多允许对同一个 Host 建立六个TCP 连接