java面试（十一）

1、你对HTTP的了解有哪些？

HTTP:超文本传输协议。使用的是可靠的数据传输协议，在传输的过程中不会被损坏或产生混乱。

常见的HTTP方法/请求方式有：GET,POST,PUT,DELETE，HEAD等。

• GET:从服务器向客户端发送命名资源
• PUT:将来自客户端的数据存储到一个命名的服务器资源中去
• DELETE从服务器中删除命名资源
• POST:将客户端数据发送到一个服务器网关应用程序
• HEAD:仅发送命名资源响应中的HTTP首部

2、IO复用了解吗？怎么实现线程安全？IO阻塞？

I/O复用就是单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流.select, poll, epoll 都是I/O多路复用的具体的实现，

select 会修改传入的参数数组，这个对于一个需要调用很多次的函数，是非常不友好的。

· select 如果任何一个sock(I/O stream)出现了数据，select 仅仅会返回，但是并不会告诉你是那个sock上有数据，于是你只能自己一个一个的找，10几个sock可能还好，要是几万的sock每次都找一遍。

· select 只能监视1024个链接，linux 定义在头文件中的，参见FD_SETSIZE。

· select 不是线程安全的，如果你把一个sock加入到select, 然后突然另外一个线程发现，尼玛，这个sock不用，要收回。

对不起，这个select 不支持的，如果你丧心病狂的竟然关掉这个sock, select的标准行为是。。呃。。不可预测的， 这个可是写在文档中的哦.

“If a file descriptor being monitored by select() is closed in another thread, the result is unspecified”
poll

•  poll 去掉了1024个链接的限制，于是要多少链接呢， 你开心就好。
• · poll 从设计上来说，不再修改传入数组，不过这个要看你的平台了，

但是poll仍然不是线程安全的， 这就意味着，不管服务器有多强悍，你也只能在一个线程里面处理一组I/O流。你当然可以那多进程来配合了，不过然后你就有了多进程的各种问题。

epoll 可以说是I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题, 比如：

· epoll 现在是线程安全的。 

· epoll 现在不仅告诉你sock组里面数据，还会告诉你具体哪个sock有数据，你不用自己去找了。 
epoll 当年的patch，现在还在，下面链接可以看得到：
/dev/epoll Home Page
可是epoll 有个致命的缺点。。只有linux支持。比如BSD上面对应的实现是kqueue。
而ngnix 的设计原则里面， 它会使用目标平台上面最高效的I/O多路复用模型咯，所以才会有这个设置。一般情况下，如果可能的话，尽量都用epoll/kqueue吧
 

实现线程安全

在java中，提供了两种方式，synchronized和Lock。

synchronized：
    在java中，每一个对象都拥有一个锁标记，monitor，称为监视器，当多个线程同时访问对象时，线程只有获得了对象的锁才能访问。

    在java中，synchronized可以用来修饰方法和代码块。当某个线程调用对象的synchronized方法和访问synchronized方法时，必须要先获得对象的锁才可以继续访问，当该线程获得锁时，其他线程暂时无法访问这个方法，只有等待这个方法执行完毕或者代码块执行完毕，这个线程才会释放该对象的锁，其他线程才能执行这个方法或者代码块。
在java 5中，java.util.concurrent.locks包下提供了另外一种方式来实现线程同步，就是Lock。

synchronized和lock区别：

• Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
• synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
• Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
• 通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。
• Lock可以提高多个线程进行读操作的效率。

　　在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

在JDK1.4中引入了一个NIO的类库，使得Java涉及IO的操作拥有阻塞式和非阻塞式两种

在阻塞模式下，若从网络流中读取不到指定大小的数据量，阻塞IO就在那里阻塞着。比如，已知后面会有10个字节的数据发过来，但是我现在只收到8个字节，那么当前线程就在那傻傻地等到下一个字节的到来，对，就在那等着，啥事也不做，直到把这10个字节读取完，这才将阻塞放开通行。

在非阻塞模式下，若从网络流中读取不到指定大小的数据量，非阻塞IO就立即通行。比如，已知后面会有10个字节的数据发过来，但是我现在只收到8个字节，那么当前线程就读取这8个字节的数据，读完后就立即返回，等另外两个字节再来的时候再去读取。

从上面可以看出，阻塞IO在性能方面是很低下的，如果要使用阻塞IO完成一个Web服务器的话，那么对于每一个请求都必须启用一个线程进行处理。而使用非阻塞IO的话，一到两个线程基