笔者带你剖析Java7.x新特性
public abstract class Reader implements Readable, Closeable
??
当然如果你需要在程序中使用自动资源管理，还需要使用API提供的新语法支持，这类语法包含在try语句块内部。看到这里你可能不禁感叹，try也能支持表达式了，是的7.x确实允许try使用表达式的语法方式实现自动资源管理，但仅限于资源类型。
使用try表达式实现自动资源管理：
try(BufferedReader reader = new BufferedReader(new FileReader("路径"));){//...}catch(Exception e){e.printStackTrace();}??
?二、“<>”类型推断运算符
List<String> list = new ArrayList<String>();
List<String> list = new ArrayList<>();
int money = 100_000_000;
??
四、switch字面值支持
Java一共为开发人员提供了2种多路分支语句，一种是大家常用的if-else，另一种则是switch语句。早在Java7.x版本之前，switch语句表达式值只能定义byte、short、int和char等4种类型，且该语句表达式值只能匹配一个，故不能重复。但是Java7.x的到来允许switch定义另一种全新的表达式值，那就是String类型。
使用String类型作为Switch表达式值：
switch("a"){case "a":System.out.println("a");break;case "b":System.out.println("b");}?
五、声明二进制字面值
?Java与C语言、C++语言直接相关。Java语言继承了C语言的语法结构，而OMT（Object Modeling Technique，对象模型）则是直接从C++语言改编而来的。所以早在Java7.x版本之前，开发人员只能够定义十进制、八进制、十六进制等字面值。但是现在你完全可以使用“0b”字符为前缀定义二进制字面值。
定义二进制字面值：
int test = 0b010101;
?
当然这里笔者需要提示你的是，虽然咱们可以直接在程序中定义二进制字面值。但是在程序运算时，仍然会将其转换成十进制展开运算和输出。
?
六、catch表达式调整
谈到catch语句的时候，不得不提到try语句，因为它们彼此之间存在相互依赖、相互关联的关系。在Java程序中捕获一个异常采用的是try和catch语句，try语句里面所包含的代码块都是需要进行异常监测的，而catch语句里面所包含的代码块，则是告诉程序当异常发生的时候所需要执行的异常处理。
谈到捕获异常，在Java7.x之前有2种方式。第一种是采用定义多个catch代码块，另外一种则是直接使用Exception（可恢复性异常超类）进行捕获。但是现在，如果你觉得不想笼统的将所有异常定义为Exception进行捕获，或者纠结于反复定义catch代码块，那么你完全可以采用Java7.x的catch表达式调整。Java7.x允许你在catch表达式内部使用“|”运算符匹配多个异常类型，当触发异常时，异常类型将自动进行类型匹配操作。
使用“|”运算符定义catch表达式：
try {//...}catch (SQLException | Exception e) {e.printStackTrace();}?
七、文件系统改变
既然本章节咱们已经谈到了Java的文件系统（FileSystem），那么必然同样也会关联到I/O技术。其实所谓I/O（Input/Output）指的就是数据输入/输出的过程，我们称之为流（数据通信通道）这个概念。比如当Java应用程序需要读取目标数据源的数据时，则开启输入流。需要写入时，则开启输出流。数据源允许是本地磁盘、内存或者是网络中的数据。
向目标数据源读取数据：
?
向目标数据源写入数据：
Java的文件系统主要由java.io及java.nio两个包内的组件构成。早在Java7.x之前，文件的操作一向都比较棘手。当然笔者这里提出的棘手，更多的是指向Java API对文件的管理的不便。比如咱们需要编写一个程序，这个程序的功能仅仅只是拷贝文件后进行粘贴。但就是连这样简单的程序逻辑实现，开发人员动则都需要编写几十行有效代码。
使用Java File API操作文件核心示例：
/* 复制目标数据源数据 */BufferedInputStream reader = new BufferedInputStream(new FileInputStream(COPYFILEPATH));byte[] content = new byte[reader.available()];reader.read(content);/* 将复制数据粘贴至新目录 */BufferedOutputStream write = new BufferedOutputStream(new FileOutputStream(PASTEFILEPATH));write.write(content);
?
通过上述程序示例我们可以看出，仅仅只是编写一个简单的文件复制粘贴逻辑，我们的代码量都大得惊人。如果你也认同上述程序的繁琐，那么你完全有必要体验下Java7.x对文件系统的一次全新改变。
Java7.x推出了全新的NIO.2 API以此改变针对文件管理的不便，使得在java.nio.file包下使用Path、Paths、Files、WatchService、FileSystem等常用类型可以很好的简化开发人员对文件管理的编码工作。
咱们就先从Path接口开始进行讲解吧。Path接口的某些功能其实可以和java.io包下的File类型等价，当然这些功能仅限于只读操作。在实际开发过程中，开发人员可以联用Path接口和Paths类型，从而获取文件的一系列上下文信息。
Path接口常用方法如下：
@Testpublic void testFile() {Path path = Paths.get("路径：/文件");System.out.println("文件节点数:" + path.getNameCount()); System.out.println("文件名称:" + path.getFileName()); System.out.println("文件根目录:" + path.getRoot()); System.out.println("文件上级关联目录:" + path.getParent()); }?
通过上述程序示例我们可以看出，联用Path接口和Paths类型可以很方便的访问到目标文件的上下文信息。当然这些操作全都是只读的，如果开发人员想对文件进行其它非只读操作，比如文件的创建、修改、删除等操作，则可以使用Files类型进行操作。
Files类型常用方法如下：
Files.copy(Paths.get("路径：/源文件"), Paths.get("路径：/新文件"));?
通过上述程序示例我们可以看出，使用Files类型来管理文件，相对于传统的I/O方式来说更加方便和简单。因为具体的操作实现将全部移交给NIO.2 API，开发人员则无需关注。
Java7.x还为开发人员提供了一套全新的文件系统功能，那就是文件监测。在此或许有很多朋友并不知晓文件监测有何意义及目，那么请大家回想下调试成热发布功能后的Web容器。当项目迭代后并重新部署时，开发人员无需对其进行手动重启，因为Web容器一旦监测到文件发生改变后，便会自动去适应这些“变化”并重新进行内部装载。Web容器的热发布功能同样也是基于文件监测功能，所以不得不承认，文件监测功能的出现对于Java文件系统来说是具有重大意义的。
?
提示：
就事论事而言，Java7.x的文件监测功能多少存在一些性能和功能上的缺陷。但随着Java后续版本的迭代，笔者相信会有那么一天，足以让某些整天在论坛上打口水战的“高手”们闭嘴。
?
如果在程序中需要使用Java7.x的文件监测功能，那么我们务必需要了解java.nio.file包下的WatchService接口。WatchService接口不仅作为监测服务，还管理着具体的监控细节。
我们可以通过使用java.nio.file包下的FileSystems类型，并调用FileSystems类型的newWatchService()方法，从而获取到WatchService接口的对象实例。
获取WatchService接口实例：
WatchService watchService = FileSystems.getDefault().newWatchService();
?
文件监测是基于事件驱动的，事件触发是作为监测的先决条件。开发人员可以使用java.nio.file包下的StandardWatchEventKinds类型提供的3种字面常量来定义监测事件类型，值得注意的是监测事件需要和WatchService实例一起进行注册。
StandardWatchEventKinds类型提供的监测事件：
1、ENTRY_CREATE：文件或文件夹新建事件；
2、ENTRY_DELETE：文件或文件夹删除事件；
3、ENTRY_MODIFY：文件或文件夹粘贴事件；
?
使用WatchService类型实现文件监控完整示例：@Testpublic void testWatch() {/* 监控目标路径 */Path path = Paths.get("C:/");try {/* 创建文件监控对象 */WatchService watchService = FileSystems.getDefault().newWatchService();/* 注册文件监控的所有事件类型 */path.register(watchService, ENTRY_CREATE, ENTRY_DELETE,ENTRY_MODIFY);/* 循环监测文件 */while (true) {WatchKey watchKey = watchService.take();/* 迭代触发事件的所有文件 */for (WatchEvent<?> event : watchKey.pollEvents())System.out.println(event.context().toString() + " 事件类型："+ event.kind());if (!watchKey.reset())return;}} catch (Exception e) {e.printStackTrace();}}??
通过上述程序示例我们可以看出，使用WatchService接口进行文件监控非常简单和方便。首先我们需要定义好目标监控路径，然后调用FileSystems类型的newWatchService()方法创建WatchService对象。接下来我们还需使用Path接口的register()方法注册WatchService实例及监控事件。当这些基础作业层全部准备好后，我们再编写外围实时监测循环。最后迭代WatchKey来获取所有触发监控事件的文件即可。
?
提示：
如果在项目中使用上述程序示例，笔者建议你最好将这段监控代码进行异步化。因为死循环会占用主线程，后续代码将永远得不到执行机会。
?
八、探讨Java I/O模型
在基于分布式的编程环境中，系统性能的瓶颈往往由I/O读写性决定。这是不可否认的事实，也是众多开发人员首要考虑的优化问题。如果在Windows环境下我们使用阻塞I/O模型来编写分布式应用，其维护成本的往往超出你的想象。因为客户端的链接数量直接决定了服务器内存开辟的线程数量 * 2（包含：接受线程、输出线程），并且这些线程是无法采取线程池优化的，因为线程的执行之间大于其创建和销毁时间。长时间的大量并发线程挂起，不仅CPU要做实时任务切换，其整体物理资源都将一步步被蚕食，直至最后程序崩溃。在早期的网络编程中，采取阻塞I/O模型来编写分布式应用，唯一能做性能优化只有采取传统的硬件式堆机。在付出高昂的硬件成本开销时，其项目的维护性也令开发人员头痛。而且在实际的开发过程中，大部分开发人员会选择将项目部署在Linux下运行。跟Windows内核结构不同的是，Linux环境下是没有真正意义上的线程概念。其所谓的线程都是采用进程模拟的方式，也就是伪线程。笔者希望大家能够明白，对于并发要求极高的分布式应用，一旦采用阻塞IO模型编写就等于自寻死路。
Java的I/O模型由同步I/O和异步I/O构成。同步I/O模型包含：阻塞I/O和非阻塞I/O，而在Windows环境下只要调用了IOCP的I/O模型，就是真正意义上的异步I/O。
Java的I/O模型示例图：
?
IOCP（Input/Outut Completion Port，输入/输出完成端口）简单来说是一种系统级的高性能异步I/O模型。应用程序中所有的I/O操作将全部委托给操作系统线程去执行，直至最后通知并返回结果。Java7.x对IOCP进行了深度封装，这使得开发人员可以使用IOCP API编写高效的分布式应用。当然IOCP仅限于使用在Windows平台，因而无法在Linux平台上使用它（Linux平台上可以通过Epoll模拟IOCP实现）。
?
提示：
有过网络编程经验的开发人员都应该明白，在Windows平台下性能最好的I/O模型是IOCP，Linux平台下则是EPOLL。但是EPOLL并不算真正意义上的异步I/O，EPOLL只是在尽可能的模拟IOCP而已。因为按照Unix网络编程的划分，多路复用I/O仍然属于同步I/O模型，也就是说EPOLL其实是属于多路复用I/O。
简单来说异步I/O的特征必须满足如下2点：
1、I/O请求与I/O操作不会阻塞；
2、并非程序自身完成I/O操作，由操作系统线程处理实际的I/O操作，直至最后通知并返回结果；
?
早在Java4.x的时候，NIO（Java New Input/Output，Java新输入/输出）的出现，使得开发人员可以彻底从阻塞I/O的噩梦中挣脱出来。但编写NIO的成本较大，学习难度也比较高，使得诸多开发人员望而却步（目前比较成熟的NIO Frameworks有：Mina、Netty）。但理解非阻塞I/O的原理还是非常有必要，先来观察下述采用阻塞I/O模式编写的分布式应用示例：
@Testpublic void testServer() {try {ServerSocket server = new ServerSocket(8888);Socket clist = server.accept();BufferedReader reader = new BufferedReader(new InputStreamReader(clist.getInputStream()));/* 未收到I/O请求时阻塞 */System.out.println(reader.readLine());} catch (Exception e) {e.printStackTrace();}}??
I/O的工作内容我们可以根据其性质划分为2部分：I/O请求和I/O操作。上述程序示例我们采用的是阻塞I/O模型，可以很明确的发现当客户端成功握手服务端后，如果服务端并没有收到客户端的I/O请求，服务端会在reader.readLine()方法处阻塞。直到成功接收到I/O请求后，服务端才会开始执行实际的I/O操作。运用阻塞I/O模式进行分布式编程，为了保证服务端与客户端集合的成功会话，我们不得不为每一条客户端连接都开辟独立的线程执行I/O操作。当然在实际的开发过程中，或许已经没有开发人员会做这么荒唐的事情了。
非阻塞I/O和阻塞I/O最大的不同在于，非阻塞I/O并不会在I/O请求时产生阻塞。也就是说如果服务端没有收到I/O请求时，非阻塞I/O会“持续轮循”I/O请求，当有请求进来后就开始执行I/O操作并阻塞请求进程。Java7.x允许开发人员使用IOCP API进行异步I/O编程，这使得开发人员不必再关心I/O是否阻塞。因为应用程序中所有的I/O操作将全部委托给操作系统线程去执行，直至最后通知并返回结果。
?
九、Swing Framework（JSR 296规范）支持
笔者其实对Swing非常厌恶，如果可以的话笔者希望Oracle能够废除掉Swing这项技术。早在08年的时候笔者由于项目需要，曾饱受Swing的折磨。繁琐的布局、组件加载优化、冗长代码维护等这些令人痛苦和发指的问题，笔者相信使用过Swing的人开发人员都能发出相同的感叹。
早期的Java GUI（图形用户界面）主要由AWT技术主导，但随着用户对胖客户端技术的丰富度要求逐渐提高，AWT主键逐渐被Swing替代。Swing其实继承于AWT，并提供有更加绚丽的视图组件效果。何况相对于重量级的AWT组件来说，Swing显得更加轻量。
笔者刚才说过，Swing虽然相对于AWT来说组件内容更加丰富，但仍然掩盖不了其繁琐的操作实现。如果对组件性能有过高要求，或者需要实现快速开发，笔者更建议你使用SWT或者JFace技术（无需指望使用IDE工具进行可视化编程，因为这纯粹是吃力不讨好）。因为这2种技术可以看成是Swing的过渡，且相对Swing来说性能和丰富度更加优秀。
既然Java7.x对Swing仍不忘眷顾优化，那希望大家还是支持一下吧。从官方声明可以看出，JSR 296规范的目标是简化Swing的开发难度，且提供有更加丰富的组件资源。如果对于从未接触过Swing编程的开发人员，笔者倒是建议你尝试一下，或许你并不反感。
?
十、JVM内核升级之Class Loader架构调整
类装载器（Class Loader）属于JVM体系结构的重要组成部分，它是将Java类型装载进JVM内部的关键一环。它使得Java类型可以动态的被装载到JVM内部解释并运行。
在JVM内部存在着2种类型的类装载器：非自定义类装载器和自定义类装载器 。非自定义类装载器负责装载Java API中的类型及Java程序中的类型，而自定义类装载器能够使用自定义的方式来装载其类型。不同类型的类装载器所装载的类型将被存放于JVM内部不同的命名空间中。
非自定义类装载器由JVM内部3个核心类装载器构成：
1、BootStrap ClassLoader；
2、ExtClassLoader；
3、AppClassLoader；
?
BootStrap ClassLoader也称为启动类装载器，它是JVM内部最顶层的类装载器。BootStrap ClassLoader主要负责装载核心Java API中的类型。ExtClassLoader负责装载扩展目录下的类型。AppClassLoader则负责装载ClassPath（Java应用类路径）下指定的所有类型。其中ExtClassLoader和AppClassLoader都属于BootStrap ClassLoader的派生类装载器。
在Object内部封装着一个通过JNI（Java Native Interface，Java本地接口）方式调用的getClass()本地方法，该方法返回一个Class类型。对于开发人员而言，允许直接调用其getClassLoader()方法获取类装载器实例。
使用getClassLoader()方法获取类装载器：
@Testpublic void testClassLoader() throws Exception {/* BootStrap ClassLoader装载Java API中的类型 */ClassLoader loader = System.class.getClassLoader();System.out.println(null != loader ? loader.getClass().getName(): loader);/* ExtClassLoader装载扩展目录下的类型 */System.out.println(CollationData_ar.class.getClassLoader().getClass().getName());/* AppClassLoader装载ClassPath下指定的所有类型 */System.out.println(this.getClass().getClassLoader().getClass().getName());}?
通过上述程序示例我们可以看出，System类型是被BootStrap ClassLoader所装载的。但程序的输出结果却是Null，当然这并不代表BootStrap ClassLoader不存在。因为BootStrap ClassLoader并不是采用Java语言编写，而是由C++语言编写并嵌入在JVM内部，所以开发人员无法获取其实例。CollationData_ar类型属于jre\lib\ext目录下的派生类，由ExtClassLoader装载。当前类则由AppClassLoader负责装载。
在此笔者要提示大家，ExtClassLoader和AppClassLoader都是采用Java语言编写。所以ExtClassLoader和AppClassLoader本身也都是Java类型，都会被最顶层的类装载器BootStrap ClassLoader装载，最后才会装载各自管辖范围内的类型。
谈到ClassLoader的架构，我们不得不提及双亲委派模型。在JVM内部，类装载器装载类型所采用的便是双亲委派模型机制。比如AppClassLoader需要将一个类型装载进JVM内部，首先其自身并不会立即装载，而是将目标类型委派给上一级，也就是ExtClassLoader。ExtClassLoader接着再继续委派给BootStrap ClassLoader。在JVM内部最顶层的类装载器就是BootStrap ClassLoader，首先由它负责装载目标类型及其关联或依赖的所有类型。如果BootStrap ClassLoader装载失败，则退回给ExtClassLoader装载。如果ExtClassLoader也无法装载，最后只能退回给AppClassLoader继续装载。最后当AppClassLoader都无法装载的时候，便会抛出ClassNotFoundException异常（开发人员可以在捕获ClassNotFoundException异常的时候重写ClassLoder类型的findClass()方法实现自定义类型装载）。
类装载器架构示例：
?
类装载器除了需要负责类型的装载，还需要负责验证目标类型的正确性、属性内存分配、解析符号引用等操作。JVM通过装载、连接和初始化一个Java类型，使其可以被运行时的Java应用程序所使用。其中装载就是把二进制形式的Java类型写入进JVM内部。连接则是把已经写入进JVM中的二进制形式的类型合并到JVM的运行时状态中去。然而连接阶段又分成了3个步骤：验证、准备和解析。“验证”步骤确保了Java类型的数据格式，“准备”步骤则负责为目标类型分配所需的内存空间，“解析”步骤负责把常量池中的符号引用转换为直接使用。“验证”和“解析”这2个步骤都是为最后的初始化工作做准备。
类型生命周期示例：
?
Java7.x在上述ClassLoader架构的基础之上，进行了一些细微调整。在早期开发人员如果想要实现自定义类装载器，恐怕只能实现ClassLoader类型并重写其findClass()方法。但由于findClass()方法是按照串行结构的方式执行，或许是出于对性能和安全的考虑。Java7.x提供了一个拥有并行执行能力的增强实现，这样一来自定义类装载器便可以通过异步方式对类型进行装载。
?
提示：
关于自定义类装载器本章笔者将不再继续讲解，如果有兴趣的朋友可以以邮件的形式告知笔者，笔者会为你提供帮助。
?
本章内容到此结束，由于时间仓库，本文或许有很多不尽人意的地方，希望各位能够理解和体谅。关于下一章的内容，笔者打算继续讲解SSJ的相关内容。
25 楼 hantsy 2013-03-02 九、Swing Framework（JSR 296规范）支持