IBM
Java 7 新特性以及在 WAS V8.5 中的安装与版本切换
什么是 Java 7--- 高层面的目标？
几乎所有平台的 Java 版本的发布，都涉及到 Java 语言本身和 JVM 的各个方面。那么对于 Java 7 来说，从 JSR 草稿中，我们得到 Java 7 的高层次的目标是：
- 兼容性 ― 任何在以前版本上运行的程序必须能不用做任何改变就能在 Java SE 7 中运行；
- 开发效率 ― 提升开发效率，最小的学习曲线；
- 性能 ― 新的并行 API 接口，引入了一种真正的异步 I/O API，使得 I/O 密集型的应用程序有更好的性能；
- 适用性 ― 在 Java 虚拟机上能够加速其他动态语言的性能；
- 可集成性 ― Java SE 7 将会包含一个新的、灵活的文件系统 API 作为 JSR203 的一部分。
Java 7 的基本的新特性
Java 语言特性的增强（JSR334）
Project Coin 主要是对 Java 语言进行一些小的改进来提高 Java 开发人员的工作效率，这些改进有：
- Switch 语句中允许使用 String 类型
清单 1. Switch 语句中允许使用 String 类型示例
- 对于通用类型实例的创建提供类型推理
清单 2. 对通用类型实例的创建提供类型推理示例
- Multi Catch 来处理多种异常类型
清单 3. Multi Catch 来处理多种异常类型示例
- 二进制常量和数字常量示例
0b10011010 34_409_066
- 自动的资源管理机制
在 Java 程序中，处理所有可能的失败路径是困难的，关闭资源也是相对困难的，因此在 Java 7 的实现中，资源管理获得了编译器的帮助，通过定义一个在资源上接口使得编译器能够自动在合适的时候来关闭资源，释放内存等资源。
自动资源管理示例
更多新的 I/O APIs（JSR203）
Java 7 为 Java 开发人员提供了更强大的 I/O 抽象和编程能力，真正的异步 I/O 接口的引入使得 I/O 操作能够被更有效的处理和控制，提供了更好的可扩展性，更灵活的线程池策略。 在 JSR 203 中包含以下的主要组件： 新的文件系统接口、支持大块访问文件属性、更改通知、绕开文件系统指定的 API，也是可插拔文件系统实现的服务提供者接口； 对套接字和文件同时提供了异步 I/O 操作的 API。可被用来建立高可扩展服务器，和多路复用 I/O 不同，异步 I/O 是让客户端启动的一个 I/O 操作，
当操作完成后向客户端发送一个通知，异步 I/O 是通过位于 java.nio.channels 包中的一个接口和类来实现的，所有的 I/O 操作都有下列 2 种形式中的一种：
- 第一个返回 java.util.concurent.Future, 代表等待结果，可使用 Future 特性等待 I/O 操作 ;
- 第二个是使用 CompletionHandler 创建的，当操作结束时，如回调系统，调用这个处理程序。
NIO.2 中所有的异步通道如下：
- AsynchronousFileChannel：读写文件异步通道 ;
- AsynchronousSocketChannel：用于套接字的一个简单异步通道 ;
- AsynchronousServerSocketChannel：用户 ServerSocket 的异步通道，accept() 方法是异步的，连接被接受时，调用 CompletionHandler;
- AsynchronousDatagramChannel：数据报套接字的异步通道 .
Java.util.concurent 更新（JSR203）
多核环境变得越来越普遍，因此相应的数据结构和算法都要做出更新以匹配多核的应用开发和运行环境。在 Java 7 中提供了新的 Fork/Join 框架，它能够很好的处理“分治”类型的问题，对于并行计算的加速提供了相应的模型，比常用的基于线程或者执行器的同步模型更有效率。Form/Join 框架采用了分治的技术和思想，获取问题后，递归的把整个大问题分成多个小的子问题，直到每个子问题都足够小，使得这些小的子问题都可以高效的解决，然后把这些子问题放入队列中等待处理（Fork 的过程），接下来等待所有子问题的结果（Join
的过程），把多个结果合并到一起。
其他的增强 :
- TransferQueue –使得生产者 / 消费者队列模型更加有效，TransferQueue 是一种 BlockingQueue，但其不同之处是提供了一个记录 的交付服务；虽然将对象成功添加到队列中之后会返回一个将对象插入 BlockingQueue 的线程，但是仅在另一个线程从队列里删除了对象之后才会返回负责将对象插入到 TransferQueue 中的线程。
- Phaser – 引入了一个全新灵活的线程同步机制，如果你喜欢等待线程结束然后继续执行其他任务，那么 Phaser 是一个好的选择。
JSR 292 – Invokedynamic 的更新（JSR203）
JVM 已经成为了更多的动态语言 ( 例如：jruby、jython、fan、clojure、 … ) 的运行时环境，但是却很难使得这些动态语言更快的运行。在 Java 7 中，引入了一个新的字节码来直接执行一个给定的方法，并在运行时重新链接这些方法。
- 包含了一个建立一个 Mutators 的模型（添加一个参数，删除一个参数，...）
- 确保 JIT 能够有效的利用这些结构使得高效的代码生成。
其他小的更新
- 类加载器的改变：通过新的“安全”API 使得并行类加载能力
- I18N — Unicode 6.0，Localeenhancement，Separate user local 和 user-interface locale
- TLS 1.2 —安全的更新
- JDBC 4.1
- Client(UI) 更新
- XML 栈的更新
IBM Java 7 特有的新特性
垃圾回收器的更新和新的垃圾回收策略 -“balanced”
IBM Java 7 提供了如下 4 种不同的垃圾回收算法：
- -Xgcpolicy:optthruput
- -Xpcpolicy:optavgpause
- -Xgcpolicy:gencon
- -Xgcpolicy:balanced
对于 IBM JDK 的 GC 策略，我们做个简单的对比，图 1、图 2、图 3 分别是采用 -Xgcpolicy:optthruput、-Xpcpolicy:optavgpause、-Xgcpolicy:gencon3 种不同 GC 策略时的 Java 线程和 GC 线程的 CPU 分配时间图。
图 1. 采用 -Xgcpolicy：optthruput 策略的 Java 线程和 GC 线程的 CPU 分配时间图
图 2. 采用 -Xgcpolicy：optavgpause 策略的 Java 线程和 GC 线程的 CPU 分配时间图
图 3. 采用 -Xgcpolicy：gencon 策略的 Java 线程和 GC 线程的 CPU 分配时间图
-Xgcpolicy：optthruput： 在 WAS V8 以前，这是默认的 GC 策略，通常来说，使用这种 GC 策略的应用程序更看重吞吐量，当整个堆用完后才会进行一次 stop the world 的 GC 操作，这时应用程序会完全停止直到 GC 完成。
-Xgcpolicy：optavgpause： 最优的平均暂停时间策略，这种 GC 策略适合于以下的应用场景：
- 应用程序无法容忍 GC 的长时间暂停，只要能减少 GC 暂停时间，适当的性能退化是可以接受的；
- 应用程序是在 64 位平台上运行的，并且使用了一个非常大的堆（超过 3 或者 4GB）;
- 应用是一个 GUI 的应用程序，对响应时间有时间上的要求。
-Xgcpolicy：gencon 使用分代并发收集策略，这种 GC 策略适用于以下的应用场景：
- 应用程序里有很多短生存周期的对象；
- 堆空间是碎片化的；
- 应用程序是基于 transaction 的，即 transaction 中的对象的生命周期在 transaction 提交后就会结束。
-Xgcpolicy：balanced
平衡的垃圾回收策略，这是 WebSphere Application Server V8 以及以后的版本中提供的新的垃圾回收策略，平衡的垃圾回收策略的宗旨是均衡暂停时间，减少一些通常与垃圾回收相关联的高成本操作的开销。将全局垃圾回收的成本分担在许多 GC 暂停上，减少整堆回收时间的影响，同时，每次暂停应该尝试执行一次独立的垃圾回收，将空闲内存返回给应用程序。平衡的垃圾回收算法使用一种动态方法来选择要回收的堆区域，类似于 gencon 策略，但是它会在每次暂停期间考虑对堆的所有部分进行回收，而不是仅仅考虑静态定义的新空间。一般来说，平衡的回收策略适用于以下的场景：
- 应用程序在 64 位平台上运行并部署了一个大于 4GB 的堆；
- 应用程序可适用 gencon 获得出色的性能，但仍然会遇到偶尔过长的全局 GC 暂停时间；
- 应用程序愿意接受性能的细微降级；
- 频繁的全局垃圾收集的应用程序；
- 相对多的大于 1MB 的数组需要分配的应用程序。
图 4. 对象堆中按区域选择的收集组
如图 4 所示，平衡的垃圾回收算法是一种基于区域“region”的垃圾回收算法，平衡的垃圾回收策略在 JVM 启动的时候，将堆内存划分有大小相等的区域，这些区域是基本的垃圾回收和分配操作单元，通过增量回收堆区域来满足我们对于暂停时间和快速释放内存给应用程序的需求，明显的这是一种部分垃圾回收集（PGC）的方法。每个 PGC 选择哪些区域来纳入收集组呢？主要是通过下面的 2 个要素来决定的，如图 4 所示：
- Newly Allocated 区域始终是要在回收组里，通常来说，Newly Allocated 区域里的对象大部分都具有较高的死亡率；
- 全局标记阶段发现的回收区域，一般来说，这些区域都比较零散，在图 4 中 Fragmented 所示的部分即为全局标记极端发现的回收区域。但是对于这些区域的回收要做碎片整理的工作。
Java 7 在 WebSphere Application Server V8.5 中的安装配置和版本切换
在 WebSphere Application Server V8.5 中默认的 JDK 是 Java 6，用户可以通过 WebSphere Application Server 提供的命令或者通过 admin console 来对每个 JVM 使用的 JDK 进行配置和版本切换。
如何获取最新版本的 IBM JDK 7?
在 IBM developWorks 网站上
http://www.ibm.com/developerworks/java/jdk/，你可以下载到各个版本的 IBM JDK。
在 WebSphere Application Server V8.5 中，Java 7 作为一个插件包的形式来提供的，用户可以在安装的时候选择安装 Java 7 到 WebSphere Application Server V8.5 中，这样就可以使用 IBM Java 7 的新特性，以获得更好的性能，那么如何通过 Installation Manager 来安装 WebSphere Application Server V8.5 和 Java 7，以及如何进行 Java 的版本切换呢？下面的步骤将为你一步一步的解答
. 一般来说，可以先安装好 WAS，然后再通过 IM 来安装 Java 7，或者同时安装 WAS 和 Java 7。
在 Installation Manager 的 Preference 中设置好 Java 7 的 repository，然后在安装的选项中就会出现如下图的可选项：
图 5. Installation Manager 中 JDK7 安装选项
然后点击下一步，一路默认下去，就可以在 WAS 中安装好 Java 7。 安装完成后，在你的 WAS 的安装目录下就会多出来一个 java_1.7_XX 的目录，这就是 Java 7 的安装目录。但是 WAS 8.5 中默认的 JDK 版本依然是 Java 6. 那么如何进行版本的切换，推荐的的方法：
- 安装 WAS V8.5；
- 安装 Java 7 可选包；
- 使用‘managesdk’命令设置 Java 7 作为默认的 JDK；
- 创建一个 profile。
WAS V8.5 中 JDK 版本的切换是通过“managesdk”来控制完成的，命令“managesdk”控制哪个版本的 JVMs 被在 WAS 中使用，它有以下的功能：
- 列出 WAS V8.5 中所有可用的 JVMs；
- 关联和配置 JVMs 到 profiles；
- 这个命令位于 app_server_root/bin 目录下。
列出当前产品中所有可用的 Java SDK：
图 6. 列出当前产品中所有可用的 Java SDK：
设置 Java 7 为新的 Profile 的默认 JDK：
图 7. 设置 Java 7 为新的 Profile 的默认 JDK：
使得 Java 7 SDK 在所有的 profiles 里生效：
图 8. 设置 Java 7 为新的 Profile 的默认 JDK：
Java7 版本切换可能遇到的潜在的问题，在不同版本的 JVMs 之间，必须确保下面的这些项的一致性：
- - 命令行选项
- - 属性文件
- - 用户添加的扩展和 Jar 包
- - JNI 动态链接库
- - 监控
IBM 提供了一系列的 Java 7 的监控和诊断工具来支持 Java 7，主要有：垃圾回收和内存可视化工具（GCMV）、转储分析器（Dump Analyzer）、健康中心（Health Center）以及内存分析器（Memory Analyzer）来帮助用户更好的使用 Java 7。
小结
本文介绍了 IBM Java 7 的基本新特性和新的垃圾回收算法 -balanced 的垃圾回收策略，对在 WebSphere Application Server V8.5 中如何安装 Java 7 和怎么样进行 Java 的版本切换的方法做了相应的介绍。
本文来自：http://www.ibm.com/developerworks/cn/java/j-lo-java7was8/index.html