面试问题（一）

1.restful的好处
（1）每一个URI代表一种资源，独一无二；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。
REST最大的几个特点为：资源、统一接口、URI和无状态。
● URL具有很强可读性的，具有自描述性；
● 资源描述与视图的松耦合；
● 可提供OpenAPI，便于第三方系统集成，提高互操作性；
● 如果提供无状态的服务接口，可提高应用的水平扩展性；
● 透明性，暴露资源存在。
充分利用 HTTP 协议本身语义。
无状态，这点非常重要。在调用一个接口（访问、操作资源）的时候，可以不用考虑上下文，不用考虑当前状态，极大的降低了复杂度
HTTP 本身提供了丰富的内容协商手段，无论是缓存，还是资源修改的乐观并发控制，都可以以业务无关的中间件来实现。
http://blog.csdn.net/qq_23211905/article/details/76572949
http://www.infoq.com/cn/articles/understanding-restful-style/
缺点：
一个适用于简单操作的接口规范而已，无规矩不成方圆，复杂操作并不适用，还是看业务发展需求的
适合CRUD并且只适合CRUD，有的浏览器可能不支持POST、GET之外的提交方式，要特殊处理，API容易给让误解中能进行增、删、查、改等操作
2.数据库的存储引擎
http://blog.csdn.net/qq_23211905/article/details/72230981
3.为什么redis读写快
edis是Nosql数据库中使用较为广泛的非关系型内存数据库，redis内部是一个key-value存储系统。它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型，类似于Java中的map）。
Redis的高并发和快速原因很多，总结一下几点：
1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。
2. 再说一下IO，Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。
3. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。
4. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。
5. 还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。
4.抽象类和接口，接口的好处
相同点：
1.都不能被实例化
2.接口的实现类或者抽象类的子类都只有实现类接口或者抽象类中的方法后才能被实例化；
不同点：
1.接口只有定义，其方法不能再接口中实现，只有实现接口的类才能实现接口中定义的方法；抽象类可以有定义和实现，但是方法可以在抽象类中实现。
2.抽象类的子类使用extends关键字来继承抽象类。如果子类不是抽象类的话，它需要提供抽象类中所有声明的方法的实现。接口子类使用关键字implements来实现接口。它需要提供接口中所有声明的方法的实现；抽象方法可以继承一个类，实现多个接口。接口只能怪继承一个或者多个接口。
3.抽象类的方法可以有public、protected和default这些修饰符。接口属性默认public static final
接口方法默认public abstract

1.抽象类 和 接口 都是用来抽象具体对象的. 但是接口的抽象级别最高
2.抽象类可以有具体的方法 和属性, 接口只能有抽象方法和不可变常量
3.抽象类主要用来抽象类别,接口主要用来抽象功能.
4、抽象类中，且不包含任何实现，派生类必须覆盖它们。接口中所有方法都必须是未实现的。
好处：
1、重要性：在Java语言中， abstract class 和interface 是支持抽象类定义的两种机制。正是由于这两种机制的存在，才赋予了Java强大的 面向对象能力。
2、简单、规范性：如果一个项目比较庞大，那么就需要一个能理清所有业务的架构师来定义一些主要的接口，这些接口不仅告诉开发人员你需要实现那些业务，而且也将命名规范限制住了（防止一些开发人员随便命名导致别的程序员无法看明白）。
3、维护、拓展性：比如你要做一个画板程序，其中里面有一个面板类，主要负责绘画功能，然后你就这样定义了这个类。
4.安全、严密性：接口是实现软件松耦合的重要手段，它描叙了系统对外的所有服务，而不涉及任何具体的实现细节。这样就比较安全、严密一些（一般软件服务商考虑的比较多）。
5.B-Tree和B+tree树
B-tree又叫平衡多路查找树。
在B-树中查找给定关键字的方法是，首先把根结点取来，在根结点所包含的关键字K1,…,Kn查找给定的关键字（可用顺序查找或二分查找法），若找到等于给定值的关键字，则查找成功；否则，一定可以确定要查找的关键字在Ki与Ki+1之间，Pi为指向子树根节点的指针，此时取指针Pi所指的结点继续查找，直至找到，或指针Pi为空时查找失败。
1.定义任意非叶子结点最多只有M个儿子；且M>2；
2.根结点的儿子数为[2, M]；
3.除根结点以外的非叶子结点的儿子数为[M/2, M]；
4.每个结点存放至少M/2-1（取上整）和至多M-1个关键字；（至少2个关键字）
5.非叶子结点的关键字个数=指向儿子的指针个数-1；
6.非叶子结点的关键字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]；
7.非叶子结点的指针：P[1], P[2], …, P[M]；其中P[1]指向关键字小于K[1]的
子树，P[M]指向关键字大于K[M-1]的子树，其它P[i]指向关键字属于(K[i-1], K[i])的子树；
8.所有叶子结点位于同一层；
B-树的搜索，从根结点开始，对结点内的关键字（有序）序列进行二分查找，如果
命中则结束，否则进入查询关键字所属范围的儿子结点；重复，直到所对应的儿子指针为
空，或已经是叶子结点；
B-树的特性：
1.关键字集合分布在整颗树中；
2.任何一个关键字出现且只出现在一个结点中；
3.搜索有可能在非叶子结点结束；
4.其搜索性能等价于在关键字全集内做一次二分查找；
5.自动层次控制；

B+-tree：是应文件系统所需而产生的一种B-tree的变形树。
一棵m阶的B+-tree和m阶的B-tree的差异在于：
1.有n棵子树的结点中含有n个关键字； (B-tree是n棵子树有n-1个关键字)
2.所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接。 (B-tree的叶子节点并没有包括全部需要查找的信息)
3.所有的非终端结点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。 (B-tree的非终节点也包含需要查找的有效信息)

a) 为什么说B+树比B-tree更适合实际应用中操作系统的文件索引和数据库索引？
1) B+-tree的磁盘读写代价更低
B+-tree的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B-tree更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
举个例子，假设磁盘中的一个盘块容纳16bytes，而一个关键字2bytes，一个关键字具体信息指针2bytes。一棵9阶B-tree(一个结点最多8个关键字)的内部结点需要2个盘快。而B+-tree内部结点只需要1个盘快。当需要把内部结点读入内存中的时候，B-tree就比B+-tree多一次盘块查找时间(在磁盘中就是盘片旋转的时间)。
2) B+-tree的查询效率更加稳定
由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
引用于：http://blog.csdn.net/hbhhww/article/details/8206846

6.tcp 三次握手，4次挥手详细过程
什么是tcp的三次握手？
第一次握手：客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态，等待服务器确认。
第二次握手：服务器收到syn包，必须确认客户端的syn(ack=j+1),同时自己也发送一个syn包(syn=k), 即SYN+ACK包,此时服务器进入SYN_RECV状态
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1),此包发送完毕，客户端和服务器进入ESTABLISHED(建立完成)状态，完成三次握手。
当然，需要注意：握手过程中，传输的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传出数据。
理想状态下，tcp一旦建立连接，在通信双方的任何一方，未主动关闭连接之前，tcp连接都将一直保持下去。
然而，断开连接时，服务器和客户端都可以主动发起断开tcp连接的请求，断开过程需要,’四次握手’，如上图红色虚线部分。
四次挥手
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务器TCP状态迁移：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
第一阶段 客户机发送完数据之后，向服务器发送一个FIN数据段，***为i；
1.服务器收到FIN(i)后，返回确认段ACK，***为i+1，关闭服务器读通道；
2.客户机收到ACK(i+1)后，关闭客户机写通道；
（此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）
第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，***为j；
3.客户机收到FIN(j)后，返回确认段ACK，***为j+1，关闭客户机读通道；
4.服务器收到ACK(j+1)后，关闭服务器写通道。

CLOSED ：初始状态，表示没有任何连接。
LISTEN ： Server 端的某个 Socket 正在监听来自远方的 TCP 端口的连接请求。
SYN_SENT ：发送连接请求后等待确认信息。当客户端 Socket 进行 Connect 连接时，会首先发送 SYN 包，随即进入 SYN_SENT 状态，然后等待 Server 端发送三次握手中的第 2 个包。
SYN_RECEIVED ：收到一个连接请求后回送确认信息和对等的连接请求，然后等待确认信息。通常是建立 TCP 连接的三次握手过程中的一个中间状态，表示 Server 端的 Socket 接收到来自 Client 的 SYN 包，并作出回应。 ESTABLISHED ：表示连接已经建立，可以进行数据传输。
FIN_WAIT_1 ：主动关闭连接的一方等待对方返回 ACK 包。若 Socket 在 ESTABLISHED 状态下主动关闭连接并向对方发送 FIN 包（表示己方不再有数据需要发送），则进入 FIN_WAIT_1 状态，等待对方返回 ACK 包，此后还能读取数据，但不能发送数据。在正常情况下，无论对方处于何种状态，都应该马上返回 ACK 包，所以 FIN_WAIT_1 状态一般很难见到。
FIN_WAIT_2 ：主动关闭连接的一方收到对方返回的 ACK 包后，等待对方发送 FIN 包。处于 FIN_WAIT_1 状态下的 Socket 收到了对方返回的 ACK 包后，便进入 FIN_WAIT_2 状态。由于 FIN_WAIT_2 状态下的 Socket 需要等待对方发送的 FIN 包，所有常常可以看到。若在 FIN_WAIT_1 状态下收到对方发送的同时带有 FIN 和 ACK 的包时，则直接进入 TIME_WAIT 状态，无须经过 FIN_WAIT_2 状态。
TIME_WAIT ：主动关闭连接的一方收到对方发送的 FIN 包后返回 ACK 包（表示对方也不再有数据需要发送，此后不能再读取或发送数据），然后等待足够长的时间（ 2MSL ）以确保对方接收到 ACK 包（考虑到丢失 ACK 包的可能和迷路重复数据包的影响），最后回到 CLOSED 状态，释放网络资源。
CLOSE_WAIT ：表示被动关闭连接的一方在等待关闭连接。当收到对方发送的 FIN 包后（表示对方不再有数据需要发送），相应的返回 ACK 包，然后进入 CLOSE_WAIT 状态。在该状态下，若己方还有数据未发送，则可以继续向对方进行发送，但不能再读取数据，直到数据发送完毕。
LAST_ACK ：被动关闭连接的一方在 CLOSE_WAIT 状态下完成数据的发送后便可向对方发送 FIN 包（表示己方不再有数据需要发送），然后等待对方返回 ACK 包。收到 ACK 包后便回到 CLOSED 状态，释放网络资源。
CLOSING ：比较罕见的例外状态。正常情况下，发送 FIN 包后应该先收到（或同时收到）对方的 ACK 包，再收到对方的 FIN 包，而 CLOSING 状态表示发送 FIN 包后并没有收到对方的 ACK 包，却已收到了对方的 FIN 包。有两种情况可能导致这种状态：其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送 FIN 包的情况；其二，如果 ACK 包丢失而对方的 FIN 包很快发出，也会出现 FIN 先于 ACK 到达。
【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？
答：建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。