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 完成后该干点什么,具体大致有:- Future 完成后执行动作,或求取下一个 Future 的值。then...
- 多个 Future 的协调; 同时完成该怎么,其中一个完成该如何。allOf, anyOf
有时候可以把 Future 想像成与线程是一一对应的。 Read More- Future 还是一 Java 1.5 带进来的产物,但过去那么多年实际代码中却很少有直接接触, 大约它多是隐匿在各种现成框架中默默的为我们服务。Future 本身不代表着多线程,而是代表着需异步计算的结果, 将来的一个期待,至于后来真正的结果不可知。在此之前想要获得一个 Runnable 在其他线程中的计算结果颇费波折,有了 Future 加之它身后的 Callable 一切就变得简单了。
对比一下 Java 1.5 前后的下面几个概念- Callable 相当于之前的 Runnable, 只是 Callable 是有返回值的
- ExecuteService.submit(callable): Future 就类似于之前的 Thread(runnable)
只是前者 submit 后立即执行,通过 get() 获得结果,后者用 start() 方法启动,runnable 是没有结果的。如果你也不想关心 Future 的结果也能 ExecuteService.submit(runnable)
只有 callable 被提交(到线程池) 后返回的 Future 才可能会有结果, 所以下面的代码永远等不到结果Future
future = new FutureTask<>(() -> "Never");
String result = future.get();
最容易理解的 Future 基本使用代码如下: Read More
在数据库中我们一般用整数或字符串来表示枚举值(有些数据库(如 MySQL)本身带有枚举类型), 而在使用 Hibernate 时实体对象中也用 Integer 或 String 来表示枚举就不那么友好了。试想来我们这样定义实体对象的两个属性@Entity
这样的定义很不严谨,type 和 gender 理论上可取任何值,这会造成表中数据的混乱。其实 Hibernate 在 Java 实体对象中是可以直接用枚举类型与数据库中的整数或字符串映射,需用到
public class User {
.... public Integer type; //0: Individual 类型,1: Company 类型
public String gender; //可取值 Male 和 Female
}@Enumerated注解,用法如下: Read More- 在前一篇 Scala 的参数检查与断言: require, assert, assume 和 ensuring,捉摸 Scala 的断言时提到了 JDK 内置对断言的粗略支持,也就是
assert语句,并且默认该特性是被关掉,需-ea开启。assert object != null;
还进一步接触了 Scala 的
assert object != null : "object can't be null";Predef方法require,assert,assume, 和ensuring是怎么检验参数与断言运算结果的,Scala 的这些方法在校验失败时相应的抛出IllegalArgumentException和AssertionError异常。
JDK 7 引入了 Objects 工具类,它的三个T requireNotNull(T object)方法能对参数进行 null 值检查,null 时抛出NullPointerException
Read More - 似乎 C/C++ 的编程人员相比于 Java 更偏爱于断言,JDK 1.4 才开始引入 assert 的支持,但默认是关闭的,需要用
-ea编译选项打开,否则代码中的assert语句全被忽略,一般会在单元测试中开启该选项。简单回顾一下 JDK 自带的断言,它用两种写法assert object != null;
第一个参数是个 bool 值,断言失败只会笼统的抛出
assert object != null : "object can't be null";java.lang.AssertionError异常,并不区分是在检验方法参数还是中间运算结果。严谨来说我们会希望参数检查不通过时抛出java.lang.IllegalArgumentException; 而中间运算结果的断言不过希望抛出java.lang.AssertionError, 最好是java.lang.IllegalStateException。
很多时候我们不会去使用-ea编译选项,也就是主动放弃了 JDK 本身的断言功能。介于两个因素(不同的断言错误和默认的断言选项关闭),Scala 为我们提供了更方便的参数检查与断言方法,它们来自于 Predef, 其所定义的方法可以直接使用
Read More - 当我们调用 Hibernate 的 saveOrUpdate() 或 JPA 的 save() 方法的 Hibernate 实现时,都会做两步操作:1)按 ID 查询记录是否已存在,2)不存在插入新记录,存在则更新原记录。这种两步操作其实可以在 SQL Server 和 HSQLDB 中一条语句完成,这就是本文要介绍的
merge into语句。感觉到用数据库自己的特性,并且一条语句会比saveOrUpdate()两步操作性能要好,还需实测。
之所以把 SQL Server 和 HSQLDB 扯到一块来讲,是因为我们在实际项目中的单元测试是基于 HSQLDB 内存数据库的。merge into如其名所示,它应该是给予我们便利的去根据把一个表中符合条件的记录合并到另一个表中去。我们这里只利用它的这特性去实现类似 Hibernate 的saveOrUpdate()操作。
假设我们有一个简单的表1CREATE TABLE user ( 2 id INT, 3 name VARCHAR(32), 4 address VARCHAR(128) 5);
如果指 id 的记录已存在更新原来记录的 name 和 address, 不存在则插入新记录 Read More - 在 Java 中对于泛型类型,比如这样简单的类定义
class Processor<T> {}
如果直接初始化时要指定具体类型的话,我们可以这么写Processor<String> processor = new Processor<>(); //Java 7 及以上版本
Spring 对基本泛型的初始化
如果我们要用 Spring 容器来初始化这个类,比如给上面那个类加个 @Named 注解@Named
这时候我们通过
class Processor<T> {
}beanFactory.getBean(Processor.class)得到的是一个什么样的实例呢?Spring 怎么知道要指定什么具体类型呢?很简单,任何不确定的情况都是 Object。所以通过容器得到的Processor实例相当于用下面代码构造出来的Processor processor = new Processor(); //更准确来讲是 Processor<Object> processor = new Processor<>();
再进一步,对于有上限约束的泛型定义,Spring 才如何应对呢?像 Read More
我们在使用 JDBC 时, 如果把所有的 SQL 语句全写在 Java 文件中, 由于 Java 不支持 Here Document, 多行字符串要么用加号, 要么用 Java 8 的String.join()方法来连接, 同时不能对 SQL 语句进行语法加亮, 所以这样的 SQL 字符串阅读性很差. 别说为何不用 Hibernate 之类的而不直接写原始的 SQL 语句, 在操作复杂的系统时还是会用到 JdbcTemplate 吧.
所以我们希望能把 SQL 语句写在单独的*.sql文件里, 这样很多编辑器就能语法高亮显示, 或在输入时还能得到智能提示. 有种办法是把*.sql用作为属性文件, 那么在其中定义多行的 SQL 语句时就得这样select.user=select id, firstname, lastname, address \
加载后就能用
from users \
where id=?getProperty("select.user")来引用相应的语句了. 属性文件的换行与 Bash 一样, 也是用\, 但如此, 则*.sql并非一个纯粹的 SQL 文件, 不能正确的进行语法加亮, 一旦写上 SQL 的注释--就更是在添乱了.
所以我们的第二个方案是: 首先*.sql就该是一个真正的 SQL 文件, 而不是伪装的属性文件, 为了能在程序中引用每一条 SQL 语句, 我们该如何表示各自的 Key 呢? 这里的灵感仍然是来自于 Linux Shell, 在 Linux Shell 中指定执行环境的用了特殊的注释方式#!, 如#!/bin/bash
Read More
#!/usr/bin/env python关于在 JUnit 单元测试中如何断言某个函数的控制台输出已是我一个长久的问题. 虽然有控制台输出的函数有了副作用, 不能称之为一个纯函数, 在讲求函数式编程的今天, 纯函数是最好测试的, 所谓的 Data In, Data Out. 但总还是有这样的需求, 比如自己实现的某个日志框架的 Appender, 需要验证它向控制台的输出内容.
我先前在项目中的办法是, 先把把标准输出定向到一个
ByteArrayOutputStream中去, 完后把这个流转成字符串来断言它的内容, 最后恢复标准输出为System.out, 代码如下:ByteArrayOutputStream output = new ByteArrayOutputStream();
System.setOut(new PrintStream(output));System.out.print("Hello");
assertThat(output.toString(), is("Hello");
System.setOut(System.out);这样也能完成任务, 本质也是对的, 但稍显复杂了些. 今天读
Spring in Action一书, 发现它用了StandardOutputStreamLog这个 JUnit 的@Rule, 来自于 System Rules. 其实StandardOutputStreamLog类已不推荐使用, 取而代之的是 SystemOutRule, 所以应用SystemOutRule来断言控制台输出的测试方法就是 Read More
本文实践了如何连接 Kafka 生产和消费 Avro 序列化格式的数据, 不能像 NgAgo-gDNA 那样, 为保证实验内容及结果的可重复性, 文中所用的各中间件和组件版本如下:- Apache Kafka: kafka_2.11-0.10.0.1, 这个版本在初始始化生产者消费者的属性与之前版本有所不同.
- kafka-clients: Java API 客户端, 版本为 0.10.0.1
- Apache Avro: 1.8.1. 关于 Avro 序列化的内容可参见 Apache Avro 序列化与反序列化 (Java 实现)
- Java 8
Apache Kafka 消息系统设计为可以传输字符串, 二进制等数据, 但直接用于传输生产消费两端都能理解的对象数据会更友好. 所以我们这里用 Avro 的 Schema 来定义要传输的数据格式, 通信时采用自定义的序列化和反序列化类进行对象与字节数组间的转换.
以下是整个实验过程本地启动 Apache Kafka 服务
请参考 简单搭建 Apache Kafka 分布式消息系统 启动 ZooKeeper 和 Kafka 即可. 程序运行会自动创建相应的主题. 启动后 Kafka 开启了本地的 9092 端口, 程序中只需要连接这个端口, 不用管 ZooKeeper 的 2181 端口. Read More