1.说一下TCP的四次挥手
第一次挥手：客户端传送完数据后，向服务端发送释放连接的报文段，并停止发送数据，主动关闭向服务端的连接，进入fin_wait-1的状态。
第二次挥手：服务端接收到客户端发来的释放连接报文段后，向客户端发送确认报文段，然后进入cloes-wait关闭等待状态，此时tcp处于半关闭的状态，客户端到服务端的连接释放，客户端收到服务端发送的数据后，客户端进入fin_wait-2的状态，然后等待服务端发出的连接释放报文段。
第三次挥手：服务端发送完数据后，向客户端发送释放连接的报文段，并停止发送数据，进入last-ack（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到服务端发送来的释放连接报文端后，对此发出确认报文段，进入time-wait状态。此时tcp未关闭，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSE状态。
四次挥手原因：
关闭连接时，被动关闭方可能还需要发送一些数据后，再发送FIN报文表示同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的，所以需要四次挥手。
2.为什么四次挥手需要有2MSL等待时间
什么是2MSL
MSL是Maximum Segment Lifetime英文的缩写，即"报文最大生存时间"， 他是任何报文在网络中存在的最长时间，超过这个时间报文将被丢弃。2MSL即2倍的报文最大存活时间
TCP四次挥手谁需要等待
主动发起关闭的一段需要等待，在第四次挥手时，主动发起关闭方发送完ACK包后就进入了TIME_WAIT状态，必须在此状态停留两倍的MSL时间
为什么需要等待2MSL
因为当主动发起关闭方发送完最后一个ACK包后无法确认对方是否有收到这个ACK包，所以2MSL的时间能保证如果对方没收到会重发第三次挥手的FIN包，且这个包有足够的时候发送回来。如果在这个时间内还没收到重发的FIN包，便可以证明对方已收到该ACK包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。
3.当有大量连接建立，但是没有发送数据，服务器会怎么做
如果TCP连接的双方都没有向对方发送数据，则在两个TCP模块之间不交换任何信息。
两个应用进程–客户进程或服务器进程都没有使用应用级的定时器来检测非活动状态，而这种非活动状态可以导致应用进程中的任何一个终止其活动。
许多时候服务器希望知道客户主机是否崩溃并关机或崩溃又重新启动，许多实现提供的保活定时器可以提供这种能力。
保活功能主要是为服务器应用程序提供的，服务器应用希望知道客户主机是否崩溃。保活功能试图在服务器端检测到这种半开放的连接。
如果一个给定的连接在两个小时之内没有任何动作，则服务器就向客户发送一个探查报文段，客户主机必须处于一下4个状态之一：
- 客户主机依然正常运行，并从服务器可达。客户端TCP响应正常，而服务器也知道对方是正常工作的。服务器在两个时以后将保活定时器复位。如果在两个小时定时器到时间之前有应用程序的通信量通过此链接，则定时器在交换数据后的未来2小时再复位
- 客户主机已经崩溃，并且关闭或正在重新启动。在任何一种情况下，客户的TCP都没有响应，服务器将不能够收到探查的响应。–会返回诸如“连接超时”之类的信息。
- 客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应，但是这个响应是一个复位，使得服务器终止这个连接。 – 会返回诸如“连接被对方复位”
- 客户主机正常运行，但是从服务器不可达。与（2）相同。
在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会有效。如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，但是这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。如果你真的要确认对端是否活着，那么应该自己实现心跳包，而不是依赖于这个保活定时器。
4.一秒钟之内如果有百万级的请求到达服务器会发生什么
服务器如果承受不住，或者它架构设计不足以支持的话，就会导致服务器奔溃。
1.内存的问题。
2.设计上的局限，设计上就不是为大负载高并发来做的。
如果可以：应该实现负载均衡，熔断降级，并发处理，缓存处理，队列处理
5.说一下什么是网络拥塞以及TCP怎么避免网络拥塞
网络拥塞（congestion）是指在分组交换网络中传送分组的数目太多时，由于存储转发节点的资源有限而造成网络传输性能下降的情况。当网络发生拥塞时，一般会出现数据丢失，时延增加，吞吐量下降，严重时甚至会导致“拥塞崩溃”
TCP是通过流量控制和拥塞控制避免网络拥塞
流量控制：接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制
拥塞控制：拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。
6.Java中的线程安全怎么理解的？保证线程安全有哪些方式？
JAVA线程安全从总体上来说，是指Java对象在多线程运行环境下的一种特性，表现为常规（区别于特殊调用情况）情况下每次调用都能得到正确的逻辑结果。从本质上来说，将对象的方法行为加上了同步控制逻辑，而调用者无须做其他额外的同步控制就可以安全放心的使用对象。
线程安全的实现方式
互斥同步
互斥同步是最常见的一种并发正确性保障手段，同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条线程使用。而互斥是实现同步的一种手段，临界区，互斥量和信号量都是主要的互斥实现方式。互斥是因，同步是果，互斥是方法，同步是目的。
非阻塞同步
互斥同步最重要的问题就是进行线程阻塞和唤醒所带来的性能问题，它属于一种悲观的并发策略，总是认为只要不去做正确的同步措施就会出现问题。但是我们有了另外一个选择：基于冲突检测的乐观并发策略，通俗的说就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据发生了争用，产生了冲突，那就再进行其他的补偿措施，这种乐观的并发策略的许多实现都不需要把线程挂起，因此被称为非阻塞同步。
7.Java中如果要更新多个变量怎么做
8.知道Java中的volatile关键字吗，说一下
Java中的volatile关键字是一个类型修饰符，在JDK1.5后，对其语义进行了加强；
- 保证了不同线程对共享变量进行操作时的可见性，即一个线程修改了共享变量的值，共享变量修改后的值对其他线程立即可见；
- 通过禁止编译器、CPU指令重排序和部分happens-befor规则，解决有序性问题；
volatile可见性的实现：
- 在生成汇编代码指令时会在volatile修饰的共享变量进行写操作的时候会多出Lock前缀的指令；
- Lock前缀的指令会引起CPU缓存写回内存；
- 一个CPU的缓存回写到内存会导致其他CPU缓存了该内存地址的数据无效；
- volatile变量通过缓存一致性协议保证每个线程获得最新值；
- 缓存一致性协议保证每个CPU通过嗅探在总线上传播的数据来检查自己缓存的值是不是修改；
- 当CPU发现自己缓存行对应的内存地址被修改，会将当前CPU的缓存行设置成无效状态，重新从内存中把数据读到CPU缓存；
9.什么是内存屏障？
定义：内存屏障，也称内存栅栏，内存栅障，屏障指令等， 是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作。
语义：内存屏障之前的所有写操作都要写入内存；内存屏障之后的读操作都可以获得同步屏障之前的写操作的结果。因此，对于敏感的程序块，写操作之后、读操作之前可以插入内存屏障。
意义：为了防止编译器和硬件的不正确优化，使得对存储器的访问顺序（其实就是变量）和书写程序时的访问顺序不一致而提出的一种解决办法。 它不是一种错误的现象，而是一种对错误现象提出的解决方法。
内存屏障的分类：
- 编译器引起的内存屏障
- 缓存引起的内存屏障
- 乱序执行引起的内存屏障
10.一道数学概率题：东城有80万人，西城有20万人，一天之内有100万个电话产生，一个城里面的人可以打电话给任何人，问跨城打电话的概率是多少。
11.问一下redis，你知道redis分布式锁实现的原理吗
待改
分布式锁: 是控制分布式系统之间同步访问共享资源的一种方式。
条件：
互斥性: 在分布式系统环境下, 一个锁只能被一个线程持有.
高可用: 不会发生死锁、即使客户端崩溃也可超时释放锁.
非阻塞: 获取锁失败即返回.
过程：加锁 - 阻塞锁 - 解锁
利用 Redis set key 时的一个 NX 参数可以保证在这个 key 不存在的情况下写入成功。并且再加上 EX 参数可以让该 key 在超时之后自动删除。
所以利用以上两个特性可以保证在同一时刻只会有一个进程获得锁，并且不会出现死锁(最坏的情况就是超时自动删除 key)。
15.redis的一个命令是怎么执行的
16.redis是单线程还是多线程的，执行的命令是单线程还是多线程的
17.一道大数据分析题：40亿个无符号整数的文件，要判断一个数字是否存在，你会怎么做，要求内存1g
18.假如这40个数字需要作为黑名单，不经过磁盘IO，怎么做（利用bitmap放入redis）
19.内存操作和IO操作速度之比是多少
20.说一下Spring的IOC原理是什么