神奇好望角 The Magical Cape of Good Hope

庸人不必自扰,智者何需千虑?
posts - 26, comments - 50, trackbacks - 0, articles - 11
  BlogJava :: 首页 ::  :: 联系 :: 聚合  :: 管理

2012年2月9日

21 世纪初,Spring 框架的诞生和崛起让沉重而腐朽的 J2EE 遭到了当头棒喝,随后大批开发人员转投 Spring 阵营,呼吸间就让 J2EE 阵营大伤元气。然而这种命悬一线的危机并没有造成毁灭性的打击,尤其是对于 Java 这种提倡开放的平台而言,取长补短,互相促进才是正道。于是,JCP 委员会痛定思痛,在 2006 年推出 Java EE 5 规范,主要是对 EJB 的开发进行了极大幅度的简化。2008 年发布的 Java EE 6 引入了 CDI、BV、JAX-RS 等一系列新功能,并且以配置文件(profile)的方式让 Java EE 向轻量级迈进了一步。特别有趣的是,Spring 框架也开始提供对某些 Java EE 注解的支持,是否标志着两大阵营开始合流?Java EE 7 预定于今年下半年发布,目标是支持云计算。最近几年来,云计算一直被炒作,却从来没有一个准确的定义和规范,希望 Java EE 7 能够在 Java 界扭转这种尴尬的局面。

下面开始详细列举 Java EE 7 的新功能前瞻,数据来源于《Java Magazine 2012-01/02》中的《Cloud/Java EE: Looking Ahead to Java EE 7》一文。Java EE 7 是以“日期驱动”的方式开发的,也就是说,在计划日期到达前没有完成的功能都将被推迟到 Java EE 8。

Java EE 7(JSR-342)

  • 主题:让应用程序能够在私有或公共云上容易地运行。
  • 该平台将定义一个应用程序元数据描述符,以描述 PaaS 执行环境(例如多租户、资源共享、服务质量,以及应用程序间的依赖)。
  • 支持 HTML5、WebSocket、JSON 等新标准,并为它们一一提供 API。
  • 消除受管 Bean、EJB、Servlet、JSF、CDI 和 JAX-RS 之间不一致的地方。
  • 可能在 Web 配置文件中包含 JAX-RS 2.0 和 JMS 2.0 API 修订版。
  • 更新一些现有的技术,可能引入用于 Java EE 的并发工具(JSR-236)和 JCache(JSR-107)。

Java Persistence 2.1(JSR-338)

  • 支持多租户。
  • 支持存储过程和厂商函数。
  • 用规则(Criteria)进行更新和删除。
  • 支持数据库大纲(Scheme)的生成。
  • 持久化上下文的同步。
  • 侦听器中的 CDI 注入。

JAX-RS 2.0: The Java API for RESTful Web Services(JSR-339)

  • 客户端 API——底层使用构建者模式,可能提供上层封装。
  • 超媒体——轻松创建和处理关联了资源的链接。
  • 使用 Bean 验证框架来验证表单或查询参数。
  • @Inject 更紧密集成。
  • 服务端的异步请求处理。
  • 使用“qs”进行服务端的内容协商。

Java Servlet 3.1(JSR-340)

  • 为 Web 应用程序优化 PaaS 模型。
  • 用于安全、会话和资源的多租户。
  • 基于 NIO2 的异步 I/O。
  • 简化的异步 Servlet。
  • 利用 Java EE 并发工具。
  • 支持 WebSocket。

Expression Language 3.0(JSR-341)

  • ELContext 分离为解析和求值上下文。
  • 可定制的 EL 强迫规则。
  • 在 EL 表达式中直接引用静态方法和成员。
  • 添加运算符,例如等于、字符串连接和取大小。
  • 与 CDI 集成,例如在表达式求值前/中/后生成事件。

Java Message Service 2.0(JSR-343)

  • 简化开发——改变 JMS 编程模型,让应用程序开发变得更加简单容易。
  • 清除/澄清现有规范中的模糊之处。
  • 与 CDI 集成。
  • 澄清 JMS 和其他 Java EE 规范之间的关系。
  • 新的强制性 API允许任何 JMS 提供者能与任何 Java EE 容器集成。
  • 来自平台的多租户和其他云相关的功能。

JavaServer Faces 2.2(JSR-344)

  • 简化开发——使配置选项动态化,使复合组件中的 cc:interface 可选,Facelet 标记库的速记 URL,与 CDI 集成,JSF 组件的 OSGi 支持。
  • 支持 Portlet 2.0 桥(JSR-329)的实现。
  • 支持 HTML5 的功能,例如 HTML5 表单、元数据、头部和区段内容模型。
  • 流管理,页面导航事件的侦听器,以及 fileUploadBackButton 等新组件。

Enterprise JavaBeans 3.2(JSR-345)

  • 增强 EJB 架构以支持 PaaS,例如多租户。
  • 对在 EJB 外使用容器管理的事务进行工厂化。
  • 更进一步使用注解。
  • 与平台中的其他规范对齐和集成。

Contexts and Dependency Injection 1.1(JSR-346)

  • 拦截器的全局排序和管理内建上下文的装饰器 API。
  • 可在 Java EE 容器外启动的嵌入式模式。
  • 声明式地控制归档中的哪些包和 Bean 将被扫描。
  • 注入日志之类的静态成员。
  • 将 Servlet 事件作为 CDI 事件发送。

Bean Validation 1.1(JSR-349)

  • 与其他 Java EE 规范集成。
  • JAX-RS:在 HTTP 调用中验证参数和返回值。
  • JAXB:将约束条件转换到 XML 模式描述符中。
  • 方法级别的验证。
  • 在组集合上应用约束条件。
  • 扩展模型以支持“与”和“或”风格的组合。

JCache: Java Temporary Caching API(JSR-107)

  • 在内存中暂存 Java 对象的 API 和语义,包括对象的创建、共享访问、缓存池、失效,以及跨 JVM 的一致性。

Java State Management(JSR-350)

  • 应用程序和 Java EE 容器可使用该 API 将状态管理的任务交给具有不同 QoS 特征的第三方提供者。
  • 基于 Java SE 的调用者可通过查询状态提供者来访问状态数据。
  • 可添加具有不同 QoS 的提供者,API 调用者能够按自己的规则进行查询。

Batch Applications for the Java Platform(JSR-352)

  • 用于批处理应用程序的编程模型,以及用于调度和执行工作的运行时。
  • 为标准编程模型定义批处理工作、批处理工作步骤、批处理应用程序、批处理执行器和批处理工作管理器。

Concurrency Utilities for Java EE(JSR-236)

  • 提供一个整洁、简单且独立的 API,使其能用于任何 Java EE 容器中。

Java API for JSON Processing(JSR-353)

  • 处理 JSON 的 Java API。

posted @ 2012-02-13 22:23 蜀山兆孨龘 阅读(5747) | 评论 (0)编辑 收藏

ForkJoinPool 是 Java SE 7 新功能“分叉/结合框架”的核心类,现在可能乏人问津,但我觉得它迟早会成为主流。分叉/结合框架是一个比较特殊的线程池框架,专用于需要将一个任务不断分解成子任务(分叉),再不断进行汇总得到最终结果(结合)的计算过程。比起传统的线程池类 ThreadPoolExecutorForkJoinPool 实现了工作窃取算法,使得空闲线程能够主动分担从别的线程分解出来的子任务,从而让所有的线程都尽可能处于饱满的工作状态,提高执行效率。

ForkJoinPool 提供了三类方法来调度子任务:

execute 系列
异步执行指定的任务。
invokeinvokeAll
执行指定的任务,等待完成,返回结果。
submit 系列
异步执行指定的任务并立即返回一个 Future 对象。

子任务由 ForkJoinTask 的实例来代表。它是一个抽象类,JDK 为我们提供了两个实现:RecursiveTaskRecursiveAction,分别用于需要和不需要返回计算结果的子任务。ForkJoinTask 提供了三个静态的 invokeAll 方法来调度子任务,注意只能在 ForkJoinPool 执行计算的过程中调用它们。

ForkJoinPoolForkJoinTask 还提供了很多让人眼花缭乱的公共方法,其实它们大多数都是其内部实现去调用的,对于应用开发人员来说意义不大。

下面以统计 D 盘文件个数为例。这实际上是对一个文件树的遍历,我们需要递归地统计每个目录下的文件数量,最后汇总,非常适合用分叉/结合框架来处理:

// 处理单个目录的任务
public class CountingTask extends RecursiveTask<Integer> {
    private Path dir;

    public CountingTask(Path dir) {
        this.dir = dir;
    }

    @Override
    protected Integer compute() {
        int count = 0;
        List<CountingTask> subTasks = new ArrayList<>();

        // 读取目录 dir 的子路径。
        try (DirectoryStream<Path> ds = Files.newDirectoryStream(dir)) {
            for (Path subPath : ds) {
                if (Files.isDirectory(subPath, LinkOption.NOFOLLOW_LINKS)) {
                    // 对每个子目录都新建一个子任务。
                    subTasks.add(new CountingTask(subPath));
                } else {
                    // 遇到文件,则计数器增加 1。
                    count++;
                }
            }

            if (!subTasks.isEmpty()) {
                // 在当前的 ForkJoinPool 上调度所有的子任务。
                for (CountingTask subTask : invokeAll(subTasks)) {
                    count += subTask.join();
                }
            }
        } catch (IOException ex) {
            return 0;
        }
        return count;
    }
}

// 用一个 ForkJoinPool 实例调度“总任务”,然后敬请期待结果……
Integer count = new ForkJoinPool().invoke(new CountingTask(Paths.get("D:/")));
    

在我的笔记本上,经多次运行这段代码,耗费的时间稳定在 600 豪秒左右。普通线程池(Executors.newCachedThreadPool())耗时 1100 毫秒左右,足见工作窃取的优势。

结束本文前,我们来围观一个最神奇的结果:单线程算法(使用 Files.walkFileTree(...))比这两个都快,平均耗时 550 毫秒!这警告我们并非引入多线程就能优化性能,并须要先经过多次测试才能下结论。

posted @ 2012-02-09 10:40 蜀山兆孨龘 阅读(2674) | 评论 (2)编辑 收藏