Java中的纤程库 - Quasar

最近遇到的一个问题大概是微服务架构中经常会遇到的一个问题:

服务 A 是我们开发的系统,它的业务需要调用 BCD 等多个服务,这些服务是通过http的访问提供的。 问题是 BCD 这些服务都是第三方提供的,不能保证它们的响应时间,快的话十几毫秒,慢的话甚至1秒多,所以这些服务的Latency比较长。幸运地是这些服务都是集群部署的,容错率和并发支持都比较高,所以不担心它们的并发性能,唯一不爽的就是就是它们的Latency太高了。

简化的微服务架构

系统A会从Client接收Request, 每个Request的处理都需要多次调用B、C、D的服务,所以完成一个Request可能需要1到2秒的时间。为了让A能更好地支持并发数,系统中使用线程池处理这些Request。当然这是一个非常简化的模型,实际的业务处理比较复杂。

可以预见,因为系统B、C、D的延迟,导致整个业务处理都很慢,即使使用线程池,但是每个线程还是会阻塞在B、C、D的调用上,导致I/O阻塞了这些线程, CPU利用率相对来说不是那么高。

当然在测试的时候使用的是B、C、D的模拟器,没有预想到它们的响应是那么慢,因此测试数据的结果还不错,吞吐率还可以,但是在实际环境中问题就暴露出来了。

阅读全文

[转]Java 8:StampedLock,ReadWriteLock以及synchronized的比较

原文出处:Tal Weiss, 译文出处: 有孚

同步区域有点像拜访你的公公婆婆。你当然是希望待的时间越短越好。说到锁的话情况也是一样的,你希望获取锁以及进入临界区域的时间越短越好,这样才不会造成瓶颈。

synchronized关键字是语言层面的加锁机制,它可以用于方法以及代码块。这个关键字是由HotSpot JVM来实现的。我们在代码中分配的每一个对象,比如String, Array或者一个JSON文档,在GC的层面的对象头部,都内建了一个加锁的机制。JIT编译器也是类似的,它在进行字节码的编译和反编译的时候,都取决于特定的某个锁的具体的状态和竞争级别。

同步块的一个问题在于——进入临界区域内的线程不能超过一个。这对生产者消费者场景是一个很大的打击,尽管这里有些线程会尝试进行独占式的数据编辑,而另外一些线程只是希望读取一下数据,这个是可以和别的线程同时进行的。

读写锁(ReadWriteLock)是一个理想的解决方案。你可以指定哪些线程会阻塞别的操作(写线程),哪些线程可以和别人共同进行内容的消费(读线程)。一个美满的结局?恐怕不是。

读写锁不像同步块,它并不是JVM中内建支持的,它只不过是段普通的代码。同样的,要想实现锁机制,它得引导CPU原子地或者按某个特定的顺序来执行某些特定的操作,以避免竞争条件。这通常都是通过JVM预留的一个后门来实现的——unsafe类。读写锁使用的是CAS操作来将值直接设置到内存中去,这是它们线程排队算法中的一部分。

尽管这样,读写锁也还不够快,有时候甚至会表现得非常慢,慢到你压根儿就不应该使用它。然而JDK的这帮家伙们没有放弃治疗,现在他们带来了一个全新的StampedLock。这个读写锁使用了一组新的算法以及Java 8 JDK中引入的内存屏障的特性,这使得这个锁更高效也更健壮。

它兑现了自己的诺言了吗?让我们拭目以待。

阅读全文

更新Maven POM文件中依赖库的版本

维护一个Maven管理的Java项目的时候,有的时候需要更新项目依赖的第三方的库,比如将Spring 3.2.16升级成Spring 4.2.5。我们可以通过Maven versions插件自动化的实现。

这个插件定义了非常多的goal:

  • versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project.
  • versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available.
  • versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available.
  • versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available.
  • versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM.
  • versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version.
  • versions:update-property Sets a property to the latest version in a given range of associated artifacts.
  • versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match).
  • versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4
  • versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT.
  • versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used.
  • versions:set can be used to set the project version from the command line.
  • versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version.
  • versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version.
  • versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version.
  • versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version.
  • versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version.
  • versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version.
  • versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version.
  • versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in "Poor Man's SCM".
  • versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in "Poor Man's SCM".

也提供了三个reporting goal:

  • versions:dependency-updates-report produces a report of those project dependencies which have newer versions available.
  • versions:plugin-updates-report produces a report of those plugins which have newer versions available.
  • versions:property-updates-report produces a report of those properties which are used to control artifact versions and which properies have newer versions available.

如果你的项目中artifact的版本都是通过属性定义的,那么mvn versions:display-property-updates可以在命令行中显示可以更新的依赖的信息。

你可以手工更改这些依赖的版本,也可以通过mvn versions:update-properties自动更新定义版本的属性。

上面的命令会为你原始的pom.xml产生一个备份文件,如果没有更新问题,你可以通过 mvn versions:commit移除这个备份文件。

Vert.x 线程模型揭秘

Vert.x是一个在JVM开发reactive应用的框架,可用于开发异步、可伸缩、高并发的Web应用(虽然不限于web应用)。其目的在于为JVM提供一个Node.js的替代方案。开发者可以通过它使用JavaScript、Ruby、Groovy、Java,甚至是混合语言来编写应用。
使用Vertx.x框架,可以用JavaScript、CoffeeScript、Ruby、Python、Groovy或Java开发应用程序的组件,最终应用程序可以是混合语言构建的。

本文试图揭示Vert.x的线程模型的应用,通过源代码分析Vert.x如何使用线程池处理请求的,以及比较Netty和Vert.x使用线程池的异同。

也许你觉得奇怪,默认启动一个Vert.x Verticle实例,它只用一个线程处理事件,在多核的情况下你需要创建多个Verticle实例以充分利用多个CPU Core的性能。

阅读全文

Java Stream 详解

Stream是 Java 8新增加的类,用来补充集合类。

Stream代表数据流,流中的数据元素的数量可能是有限的,也可能是无限的。

Stream和其它集合类的区别在于:其它集合类主要关注与有限数量的数据的访问和有效管理(增删改),而Stream并没有提供访问和管理元素的方式,而是通过声明数据源的方式,利用可计算的操作在数据源上执行,当然BaseStream.iterator()BaseStream.spliterator()操作提供了遍历元素的方法。

Java Stream提供了提供了串行和并行两种类型的流,保持一致的接口,提供函数式编程方式,以管道方式提供中间操作和最终执行操作,为Java语言的集合提供了现代语言提供的类似的高阶函数操作,简化和提高了Java集合的功能。

本文首先介绍Java Stream的特点,然后按照功能分类逐个介绍流的中间操作和终点操作,最后会介绍第三方为Java Stream做的扩展。

前年年底的时候我写了一些关于Java 8 Lambda和Stream的文章,本文应该在那个时候完成。后来忙于项目和写《Scala集合技术手册》(Scala Collections Cookbook)这本书,一直没来得及写Java Stream的文章,现在这篇文章算是对 Java Stream的一个总结吧。

阅读全文

Java CompletableFuture 详解

Future是Java 5添加的类,用来描述一个异步计算的结果。你可以使用isDone方法检查计算是否完成,或者使用get阻塞住调用线程,直到计算完成返回结果,你也可以使用cancel方法停止任务的执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class BasicFuture {
public static void main(String[] args) throws ExecutionException, InterruptedException {
ExecutorService es = Executors.newFixedThreadPool(10);
Future<Integer> f = es.submit(() ->{
// 长时间的异步计算
// ……
// 然后返回结果
return 100;
});
// while(!f.isDone())
// ;
f.get();
}
}

虽然Future以及相关使用方法提供了异步执行任务的能力,但是对于结果的获取却是很不方便,只能通过阻塞或者轮询的方式得到任务的结果。阻塞的方式显然和我们的异步编程的初衷相违背,轮询的方式又会耗费无谓的CPU资源,而且也不能及时地得到计算结果,为什么不能用观察者设计模式当计算结果完成及时通知监听者呢?

很多语言,比如Node.js,采用回调的方式实现异步编程。Java的一些框架,比如Netty,自己扩展了Java的 Future接口,提供了addListener等多个扩展方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
ChannelFuture future = bootstrap.connect(new InetSocketAddress(host, port));
future.addListener(new ChannelFutureListener()
{
@Override
public void operationComplete(ChannelFuture future) throws Exception
{
if (future.isSuccess()) {
// SUCCESS
}
else {
// FAILURE
}
}
});

Google guava也提供了通用的扩展Future:ListenableFutureSettableFuture 以及辅助类Futures等,方便异步编程。

1
2
3
4
5
6
7
8
9
10
11
final String name = ...;
inFlight.add(name);
ListenableFuture<Result> future = service.query(name);
future.addListener(new Runnable() {
public void run() {
processedCount.incrementAndGet();
inFlight.remove(name);
lastProcessed.set(name);
logger.info("Done with {0}", name);
}
}, executor);

Scala也提供了简单易用且功能强大的Future/Promise异步编程模式

作为正统的Java类库,是不是应该做点什么,加强一下自身库的功能呢?

在Java 8中, 新增加了一个包含50个方法左右的类: CompletableFuture,提供了非常强大的Future的扩展功能,可以帮助我们简化异步编程的复杂性,提供了函数式编程的能力,可以通过回调的方式处理计算结果,并且提供了转换和组合CompletableFuture的方法。

下面我们就看一看它的功能吧。

阅读全文

Spymemcached的一个坑

Spymemcached 是 Memcached 的一个流行的Java client库(另一个比较著名的是原淘宝的 伯岩/庄晓丹 开发的XMemcached, 他也开发另一个Taobao开源的项目 Metamorphosis),性能表现出色,广泛应用于Java + Memcached 项目中。
Spymemcached 最早由 Dustin Sallings 开发,Dustin 后来和别人一起创办了Couchbase (原NorthScale),职位为首席架构师。2014加入Google。

阅读全文

Java8 简明教程

这是Benjamin Winterberg写的英文教程Modern Java - A Guide to Java 8,最早发表于2014年三月,当时由 ImportNew - 黄小非翻译成中文: Java 8简明教程。离原文初次发表已经快两年了,作者又陆陆续续提交多个commit,所以我根据原文以及黄小非的译文又做了修正。实际绝大部分的内容和小非翻译的一样,只有些许的变化。

Java并没有没落,人们开始认识到这一点

欢迎阅读我编写的Java 8介绍。本教程将带领你一步步认识这门语言的所有新特性。通过简单明了的代码示例,你将会学习到如何使用默认接口方法,Lambda表达式,方法引用和可重复注解。在这篇教程的最后,你还将对最新推出的API有一定的了解,例如:流控制,函数式接口,map扩展和新的时间日期API等等。
没有大段的废话,只是一些带注释的代码片段,望君喜欢。

本文最早发表在我的博客上。 你可以在Twitter上加我

阅读全文

Java RESTful框架的性能比较

在微服务流行的今天,我们会从纵向和横向分解代码的逻辑,将一些独立的无状态的代码单元实现为微服务,可以将它们发布到一些分布式计算单元或者Docker中,并在性能需要的时候及时地创建更多的服务单元。
微服务是一个概念,并没有规定服务的格式,但是很多厂商和框架都不约而同的采用RESTful的架构,尽管也有一些其它的性能很好的RPC框架。
如何在Java生态圈选择一个轻量级的RESTful框架?可以参考一些其他人的经验, 比如我翻译的: 最好的8个 Java RESTful 框架
就我个人而言,我选择框架的理由很简单:

  • 简单,轻量级
  • 性能好
  • 稳定,可靠
  • 易于开发和维护

我会首选遵循Java规范(JSR339)的框架,轻量级,便于发布到Docker容器中。 所以我不会选择Spring boot, Spring MVC, CXF等比较重的框架,也不会选择纯netty这样的太过底层,还得实现路由等基本功能框架。
因为追求轻量级,便于发布到docker容器中,我也不会考察JBOSS, Tomcat这样的JEE容器, 而是选用jetty, undertow这样的嵌入式容器。

所以,这里我挑选了几个候选者:

  1. Jersey + Grizzly
  2. Jersey + Jetty
  3. Dropwizard
  4. RESTEasy + Netty
  5. RESTEasy + Undertow

[Updated on 2015/11/18]
我增加了更多的 RESTful 框架,有些不是Jax-RS的实现,但是也有很活跃的社区。

  1. Jersey + Jetty4
  2. Spring Boot
  3. 纯Netty
  4. Vert.x
    你会发现一些有趣的测试结果。

Jersey 是Jax-RS的官方参考实现,可以很好的和其它JEE容器集成。RESTEasy是JBoss出品的框架,也很容易的和其它容器集成。Dropwizard实际上集成了Jersey, Jetty以及其它的第三方库比如它的Metrics,提供了一站式的开发,略微有些厚重。

测试相关的代码已经放在了GITHUB上: 代码

阅读全文

最好的8个 Java RESTful 框架

原文: Top 8 Java RESTful Micro Frameworks
过去的每一年,涌现出越来越多的Java框架。就像JavaScript,每个人都认为他们知道一个好的框架的功能应该是怎么样的。连我的老祖母现在也使用一个我从来没有听说过而且可能永远不会使用的框架。玩笑归玩笑,可以做几乎任何事的臃肿的框架市场已经饱和,,但是如何评判呢?

这篇文章旨在提供目前最好的 Java RESTfulful 框架。我只介绍轻量级的产品, 略过了那些臃肿的过度设计的框架。同时,我只想要他们稳定和成熟,提供简单,轻量级的特点。我只在介绍Play frameworks时打破这条规则,理由稍后给出。

在将来的项目中使用哪个 Java RESTful框架完全取决于你当前的需求。为了便于你取舍,我将列出最突出的框架功能,希望这能节省一些你的时间。

阅读全文