JDK7中新加入的文件和网络io特性称为nio2(new io 2, 因为jdk1.4中已经有过一个nio了)，包含了众多性能和功能上的改进，其中最重要的部分，就是对异步io的支持，称为java aio(asynchronous IO)。

异步io包括文件io和socket io，其中文件异步io各主流OS都提供了原生的支持，异步socket io则并未获得所有操作系统的支持。windows的IOCP，solaris等部分unix系统，已经实现了异步IO模型；而linux的epoll，bsd的kqueue等，仍属于非阻塞多路复用io模型，读写操作是同步的。

jdk在1.4版本的nio中提供了对非阻塞多路复用同步io模型的支持，在linux上基于epoll实现，在bsd上基于kqueue实现，在Windows上则是基于select/poll实现，主要因为io模型的不同，nio无法使用IOCP来实现。jdk1.7中提供对aio的支持后，带来了两方面的好处：

1. Windows上可以使用iocp了。aio在Windows上基于iocp实现，解决了Windows上java nio由于使用较原始的select/poll导致的并发能力低下问题。

windows IOCP是在94年随着NT3.5系统发布的，在17年后java终于提供了支持，这也算是个尴尬的事情吧。如果异步io是由操作系统实现(如IOCP)，可以利用硬件和驱动的异步功能，在内核态中调度线程完成数据读写，并且避免了多次内核态数据到用户态数据的拷贝操作，其性能会表现得相当优异。

在linux系统上由于aio是使用epoll来实现，其性能并不会出现提升。

2. 简化了网络变成模型。异步io相比较非阻塞多路复用模型更易理解，开发更为简单。

和多路复用的java nio相比较，可以发现，异步io是在数据读取或者写入调用已经完成的时候，再通知调用者，而非阻塞多路复用io则是在有数据就绪，可以读写的时候通知调用者，读写仍然是由调用者执行并且是阻塞的(这意味着如果要同时进行其他工作，要控制读写操作不能阻塞太长时间或者需要将其放去单独的io线程执行)。

JDK7中的java aio新增的类和接口主要有：

AsynchronousServerSocketChannel ，对应于bio中的ServerSocket和nio中的ServerSocketChannel，用于server端的网络程序。

AsynchronousSocketChannel，对云关于bio中的Socket和nio中的SocketChannel，用于client端的网络程序。

CompletionHandler，回调接口，在socket进行accept/connect/read/write等操作时，可以传入一个CompletionHandler的实现，操作执行完毕后，会调用注册的CompletionHandler。

除了CompletionHandler这种回调方式，aio中还支持返回Future对象，使用Future来设定回调操作。

Garbage-first garbage collector，简称G1 GC，是最终将用于代替Concurrent Mark-Sweep garbage collector(CMS GC)的新一代垃圾回收器。原本的计划是作为JDK7新特性的一部分发布，但其后JDK7一直在坚持不懈的跳票，G1也无法再等下去了。目前JDK1.6update14及以后版本的jvm中已经继承了G1 GC，可以使用参数-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC来启用。

G1是一个适用于服务器端、大内存、多CPU情景的垃圾收集器，主要目标是在维持高效率回收(high thoughput)的同时，提供软实时中断特性。用户可以指定一个时间上限，如果垃圾回收导致的程序暂停超过了用户设定的时间上限，会打断垃圾回收，恢复程序的执行。

G1的原理在于将堆划分成等一系列大小的区域，每一个区域都有一个对应的remembered set结构，用来记录指向这个区域中的地址的其他区域的指针。 在垃圾回收时，选择记录最少的一个区域进行，按找这种方式选择出来的区域，通常是有用数据最少、垃圾最多的区域，这也就是“Garbage-first ”名称的由来。假如没有外部的指针指向这个区域，就可以直接回收整块区域而不用进行内存Copy，这种情况真是太好了。

以区域为单位的回收，时间粒度更小，这也是实现垃圾回收软实时中断的基础。

G1付出的代价之一是额外的空间占用(用于remembered set)。

附送SUN公司的一篇论文，供想了解更多细节的人观览。