Category: Java/JEE

使用 Byte Buddy 运行时生成泛型子类

2017-02-01 | 阅读(2,301)

在上一篇中尝试了 使用 Javassist 运行时生成泛型子类，这里要用另一个更方便的字节码增加组件 Byte Buddy 来实现类似的功能, 但代码上要直白一些。就是运用 Byte Buddy 在运行时生成一个类的子类，带泛型的，给类加上一个注解，可生成类文件或 Class 实例，不过这里更进一步，实现的方法是带参数的。

用 Byte Buddy 操作起来更简单，根本不需要接触任何字节码相关的，诸如常量池等概念。与 Javassist 相比，Byte Buddy 更为先进的是能生成的类文件都是可加载运行的，不像 Javassist 生成的类文件反编译出来是看起来是正常的，但一加载执行却不那回事。

本例所使用的 Byte Buddy 的版本是当前最新的 1.6.7，在 Maven 项目中用下面的方式引入依赖

<dependency>
    <groupId>net.bytebuddy</groupId>
    <artifactId>byte-buddy</artifactId>
    <version>1.6.7</version>
</dependency>

下面是几个需要在本例中用到的类定义 阅读全文 >>

使用 Javassist 运行时生成泛型子类

2017-02-01 | 阅读(3,581)

越是复杂的项目希望使用者能愉快的编码的话，可能就要使用到字节码增强工具来暗地里做些手脚。这方面的工具有 JDK 的 Instrumentation, ASM, BCEL, CGLib, Javassist, 还有 Byte Buddy. Javassist 和 Byte Buddy 更贴近我们编码中的概念，使用起来也简单，而其他几个工具需要我们更多的了解字节码指令，以及常量池等概念。所以我着重去了解怎么运用 Javassist 和 Byte Buddy 来动态修改来生成类文件。

所以本文是系列中的第一篇，旨在以一个 Javassist 的例子来了解它的基本使用方法。本例中在运行时动态生成一个类的子类，并且是泛型的，实现了一个方法，给类加上了一个注解，最终生成一个类文件。总之尽可能的让这个例子具有代表性，同时又需控制它的复杂性。最后通过加载类文件的方式来验证前面生成的类是否是正确的，也可以直接反编译生成的类文件来查看源代码，不过实际操作中我们可能会被反编译出来的源代码欺骗。

本例所使用的 Javassist 的版本是 3.21.0-GA, 是在一个 Maven 项目中测试的，所以 Maven 的依赖是

<dependency>
    <groupId>org.javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.21.0-GA</version>
</dependency>

阅读全文 >>

Java 8 可重复注解的理解与应用

2017-01-16 | 阅读(3,847)

Java 8 之前如何重复使用注解

在 Java 8 之前我们不能在一个类型重复使用同一个注解，例如 Spring 的注解 @PropertySource 不能下面那样来引入多个属性文件

@PropertySource("classpath:config.properties")
@PropertySource("file:application.properties")
public class MainApp {}

上面的代码无法在 Java 7 下通过编译，错误是: Duplicate annotation

于是我们在 Java 8 之前想到了一个方案来规避 Duplicate Annotation 的错误: 即声明一个新的 Annotation 来包裹 @PropertySource, 如 @PropertySources

然后使用时两个注解齐上阵 阅读全文 >>

Mockito 如何 mock 返回值为 void 的方法

2017-01-16 | 阅读(27,167)

最初接触 Mockito 还思考并尝试过如何用它来 mock 返回值为 void 的方法，然而 Google 查找到的一般都会说用 doThrow() 的办法

doThrow(new RuntimeException()).when(mockObject).methodWithVoidReturn();

因为无法使用常规的 when(mockObject.foo()).thenReturn(...) 的方法。

当时我就纳闷，为何我想 mock 一个返回值为 void 的方法，却是在模拟抛出一个异常，现在想来如果一个返回值为 void 的方法，为何要去 mock 这个方法呢？

回想一个我们要 mock 一个方法的意图是什么：

  1. 在特定输入参数的情况下期待需要的输出结果(返回值)
  2. 在方法抛出某种类型异常调用者作出的反应

对于 void 返回值的方法，如果要验证有没有被调用过几次可以在事后用 verify() 方法去断言。所以基本上对于 void 返回值的方法一般可不用去 mock 它，只需用  verify() 去验证，或者就是像前面一样模拟出现异常时的情况。

所以本文并不像是去直接回答标题所示的问题: Mockito 如何 mock  返回值为  void 的方法，而是如何应对 mock  对象的  void 方法 阅读全文 >>

Mockito 中捕获 mock 对象方法的调用参数

2017-01-15 | 阅读(10,505)

Mockito 可以帮助我们创建 Mock 对象，mock 被调用的方法，断言调用次数，在方法参数不易确定的情况下还能帮我们捕获参数。下面是我们第一个问题:

为什么要捕获调用参数

在被 mocker 方法调用参数明确的情况下可无需捕获参数，例如，下面的情景：

如果 UserService 的 save(user) 最终操作的不是同一个对象，它的实现稍加变化如下 阅读全文 >>

CompletableFuture 的并发性能研究

2016-12-29 | 阅读(5,670)

今天继续探讨 CompletableFuture 的特性，它并发时的性能如何呢？我们知道集合的 stream() 后的操作是序列化进行的，parallelStream()是能够并发执行的，而用 CompletableFuture 可以更灵活的控制并发。

我们先可以对比一下 parallelStream() 与 CompletableFuture 的性能差异

假设一个这样的耗时 1000 毫秒的计算任务

分别用下面两个方法来测试，任务数可以通过参数来控制 阅读全文 >>

理解 CompletableFuture 的任务与回调函数的线程

2016-12-23 | 阅读(5,203)

继续对 CompletableFuture 的学习，本然依然不对它的众多方法的介绍，其实也不容易通过一篇述说完所有 CompletableFuture 的操作。此处重点了解下 CompletableFuture 几类操作时所使用的线程，CompletableFuture 的方法重点在它的静态方法以及实现自 CompletionStage 接口的方法，如果是意图异步化编程，反而自我标榜的 Future 中的方法用的少了。

CompletableFuture 根据任务的主从关系为

  1. 提交任务的方法，如静态方法 supplyAsync(supplier[, executor]),  runAsync(runnable[, executor])
  2. 回调函数，即对任务执行后所作出回应的方法，多数方法了，如 thenRun(action), thenRunAsync(action[, executor]), whenComplete(action), whenCompleteAsync(action[, executor]) 等

根据执行方法可分为同步与异步方法，任务都是要被异步执行，所以提交任务的方法都是异步的。而对任务作出回应的方法很多分为两个版本，如

  1. 同步方法，如 thenRun(action), whenComplete(action)
  2. 异步方法，如 thenRunAsync(action[, executor]), whenCompleteAsync(action[, executor]), 异步方法可以传入线程池，否则用默认的

因此所要理解的 CompletableFuture 的线程会涉及到任务与回调函数所使用的线程。 阅读全文 >>

Java 8 CompletableFuture 浅入

2016-12-23 | 阅读(3,298)

Java 1.5 有了 Future, 可谓是跨了一大步，继而 Java 1.8 新加入一个 Future 的实现 CompletableFuture, 从此线程与线程之间可以愉快的对话了。最初两个线程间的协调我采用过 Object 的  wait() 和 notify() , Thread 的 join() 方法，那可算是很低级的 API 了，是否很多 Java 程序都不知道它们的存在，或根本没用过它们。

如果是简单的等待所有线程完成可使用 Java 1.5 的 CountDownLatch, 这里有一篇介绍 CountDownLatch 协调线程, 就是实现的 waitAll(threads) 功能。而 Java 8 的 CompletableFuture 的功能就多去，可简单使用它实现异步方法。虽说 CompletableFuture 实现了 Future 接口，但它多数方法源自于 CompletionStage, 所以还里氏代换，用 Future 来引用 CompletableFuture 实例就很牵强了; 这也是为什么 PlayFramework 自 2.5 开始直接暴露的类型是 CompletionStage 而非其他两个。

顾名思义，CompletableFuture 代表着一个 Future 完成后该干点什么，具体大致有：

  1. Future 完成后执行动作，或求取下一个 Future 的值。then...
  2. 多个 Future 的协调; 同时完成该怎么，其中一个完成该如何。allOf, anyOf

有时候可以把 Future 想像成与线程是一一对应的。 阅读全文 >>

巩固 Java Future 的使用

2016-12-22 | 阅读(849)

Future 还是一 Java 1.5 带进来的产物，但过去那么多年实际代码中却很少有直接接触, 大约它多是隐匿在各种现成框架中默默的为我们服务。Future 本身不代表着多线程，而是代表着需异步计算的结果, 将来的一个期待，至于后来真正的结果不可知。在此之前想要获得一个 Runnable 在其他线程中的计算结果颇费波折，有了 Future 加之它身后的 Callable 一切就变得简单了。

对比一下 Java 1.5 前后的下面几个概念

  1. Callable 相当于之前的 Runnable, 只是 Callable 是有返回值的
  2. ExecuteService.submit(callable): Future 就类似于之前的 Thread(runnable)
    只是前者 submit 后立即执行，通过 get() 获得结果，后者用 start() 方法启动，runnable 是没有结果的。如果你也不想关心 Future 的结果也能 ExecuteService.submit(runnable)

只有 callable 被提交(到线程池) 后返回的 Future 才可能会有结果, 所以下面的代码永远等不到结果

Future<String> future = new FutureTask<>(() -> "Never");
String result = future.get();

最容易理解的 Future 基本使用代码如下： 阅读全文 >>

Hibernate 映射枚举(Enum) 类型的属性

2016-12-14 | 阅读(3,945)

在数据库中我们一般用整数或字符串来表示枚举值(有些数据库(如 MySQL)本身带有枚举类型), 而在使用 Hibernate 时实体对象中也用 Integer 或 String 来表示枚举就不那么友好了。试想来我们这样定义实体对象的两个属性

@Entity
public class User {
  ....
  public Integer type;  //0: Individual 类型，1: Company 类型
  public String gender;  //可取值 Male 和 Female
}

这样的定义很不严谨，type 和 gender 理论上可取任何值，这会造成表中数据的混乱。其实 Hibernate 在 Java 实体对象中是可以直接用枚举类型与数据库中的整数或字符串映射，需用到 @Enumerated 注解，用法如下： 阅读全文 >>