JAVA ’ 目录归档

比AtomicLong还高效的LongAdder 源码解析

感谢前同事的同事【刘锟洋】在本站发表此文

接触到AtomicLong的原因是在看guava的LoadingCache相关代码时,关于LoadingCache,其实思路也非常简单清晰:用模板模式解决了缓存不命中时获取数据的逻辑,这个思路我早前也正好在项目中使用到。

言归正传,为什么说LongAdder引起了我的注意,原因有二:

1. 作者是Doug lea ,地位实在举足轻重。

2. 他说这个比AtomicLong高效。 阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 比AtomicLong还高效的LongAdder 源码解析


你所不知道的有关Java 和Scala中的同步问题

原文:Things You Didn’t Know About Synchronization in Java and Scala   译者: 李杰聪

在实际应用中所有的服务端程序都需要在多线程之间进行某种同步。大多数同步已经有框架完成了,比如我们的web服务器,DB客户端和消息框架。Java和Scala提供了大量的组件用来实现稳定的多线程程序。包括对象池,并发集合,高级锁,执行上下文等。

为了更好的理解这些组件,我们深入了解一下最常用的同步原语——对象所。这个是用synchronized 关键字来实现的,在Java中它是非常流行的多线程原语。这也是其他更复杂模式的基础,比如线程池和连接池,并发集合等。

Synchronized 关键字主要用在以下两个场景:

  1. 作为方法的修饰,此方法在同一个时间只能被一个线程执行。
  2. 把一个代码块声明为临界区,任何时间只有一个线程能访问。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 你所不知道的有关Java 和Scala中的同步问题


Bug:LinkedTransferQueue的数据暂失和CPU爆满以及修复

一个因中断或者超时的调用可能会引起数据丢失和CPU爆满。

前几天读LinkedTransferQueue(以下简称ltq)的源码,想加深下对松弛型双重队列的理解,无意中发现了这个问题:),经过仔细检查后确认了这是个bug,存在于JDK1.7.0_40和刚发布的JDK8中,去google和oracle官方似乎也没有搜索到这个问题。

重现bug:先来重现下这个bug,由于对并发线程的执行顺序预先不能做任何假设,所以很可能根本就不存在所谓的重现错误的“测试用例”,或者说这个测试用例应该是某种“执行顺序”。所以我一开始的做法是copy了一份ltq的源码,通过某个地方加自旋…但是这种方法毕竟要修改源码,后来我发现直接debug进源码就可以轻易重现bug了。 阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Bug:LinkedTransferQueue的数据暂失和CPU爆满以及修复


Java那些不为人知的特殊方法

原文链接译文链接,原文作者: Peter Verhas,译者:有孚,本文最早发表于deepinmind

如果你用过反射并且执行过getDeclaredMethods方法的话,你可能会感到很吃惊。你会发现出现了很多源代码里没有的方法。如果你看一下这些方法的修饰符的话,可能会发现里面有些方法是volatile的。顺便说一句,如果在Java面试里问到“什么是volatile方法?”,你可能会吓出一身冷汗。正确的答案是没有volatile方法。但同时,getDeclaredMethods()或者getMethods()返回的这些方法,Modifier.isVolatile(method.getModifiers())的结果却是true。

immutator的一些用户遇到过这样的问题。他们发现,使用immutator(这个项目探索了Java的一些不为人知的细节)生成的Java代码使用volatile了作为方法的关键字,而这样的代码没法通过编译。结果就是这根本没法用。 阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java那些不为人知的特殊方法


4.19周六北京 GreenTea JUG活动

GreenTea JUG 是中国第一个加入JCP的组织。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 4.19周六北京 GreenTea JUG活动


Java8初体验(二)Stream语法详解

感谢同事【天锦】的投稿。投稿请联系 tengfei@ifeve.com
上篇文章Java8初体验(一)lambda表达式语法比较详细的介绍了lambda表达式的方方面面,细心的读者会发现那篇文章的例子中有很多Stream的例子。这些Stream的例子可能让你产生疑惑,本文将会详细讲解Stream的使用方法(不会涉及Stream的原理,因为这个系列的文章还是一个快速学习如何使用的)。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java8初体验(二)Stream语法详解


Java8初体验(一)lambda表达式语法

感谢同事【天锦】的投稿。投稿请联系 tengfei@ifeve.com

本文主要记录自己学习Java8的历程,方便大家一起探讨和自己的备忘。因为本人也是刚刚开始学习Java8,所以文中肯定有错误和理解偏差的地方,希望大家帮忙指出,我会持续修改和优化。本文是该系列的第一篇,主要介绍Java8对屌丝码农最有吸引力的一个特性—lambda表达式。

java8的安装

工欲善其器必先利其器,首先安装JDK8。过程省略,大家应该都可以自己搞定。但是有一点这里强调一下(Windows系统):目前我们工作的版本一般是java 6或者java 7,所以很多人安装java8基本都是学习为主。这样就在自己的机器上会存在多版本的JDK。而且大家一般是希望在命令行中执行java命令是基于老版本的jdk。但是在安装完jdk8并且没有设置path的情况下,你如果在命令行中输入:java -version,屏幕上会显示是jdk 8。这是因为jdk8安装的时候,会默认在C:/Windows/System32中增加java.exe,这个调用的优先级比path设置要高。所以即使path里指定是老版本的jdk,但是执行java命令显示的依然是新版本的jdk。这里我们要做的就是删除C:/Windows/System32中的java.exe文件(不要手抖!)。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java8初体验(一)lambda表达式语法


Java8初体验系列文章

Java8初体验系列文章,是我自学Java8的过程中把自己的理解和体会记录下来,供大家参考和讨论。

  1. lambda表达式语法
  2. Sream语法详解

未完待续。。。

ps:本人也还在Java8的学习中,所以后面文章的更新周期可能不会特别固定,敬请体谅。

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java8初体验系列文章


Callable和Future

原文链接  译文链接  译者:Greenster  校对:沈义扬
Java从发布的第一个版本开始就可以很方便地编写多线程的应用程序,并在设计中引入异步处理。Thread类、Runnable接口和Java内存管理模型使得多线程编程简单直接。但正如之前提到过的,Thread类和Runnable接口都不允许声明检查型异常,也不能定义返回值。没有返回值这点稍微有点麻烦。

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Callable和Future


Java 8 指南

原文地址译文地址,作者: Benjamin Winterberg,译者:Autumn,校对:李任

2014年3月16日

“Java is still not dead—and people are starting to figure that out.”

欢迎阅读我对 Java 8 的介绍。本指南将一步步地通过所有的新的语言特性来引导你认识Java 8。在简短的示例代码的帮助下,你将会学习到如何使用默认的接口方法、lambda表达式、方法引用以及可重复的注解。在文章的最后,你将会熟悉最新的API变化,例如:streams、函数式接口、map 扩展以及新的 Date API。

没有过多的文本 — 仅仅是一些具有注释的代码片段。一起享受吧!

阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Java 8 指南


Storm入门之第五章Bolts

本文翻译自《Getting Started With Storm》  译者:吴京润   编辑:方腾飞

第5章 Bolts

正如你已经看到的,bolts是一个Storm集群中的关键组件。你将在这一章学到bolt生命周期,一些bolt设计策略,以及几个有关这些内容的例子。

Bolt生命周期

Bolt是这样一种组件,它把元组作为输入,然后产生新的元组作为输出。实现一个bolt时,通常需要实现IRichBolt接口。Bolts对象由客户端机器创建,序列化为拓扑,并提交给集群中的主机。然后集群启动工人进程反序列化bolt,调用prepare,最后开始处理元组。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Storm入门之第五章Bolts


Storm入门之第四章Spouts

本文翻译自《Getting Started With Storm》  译者:吴京润   编辑:方腾飞

你将在本章了解到spout作为拓扑入口和它的容错机制相关的最常见的设计策略。

可靠的消息 VS 不可靠的消息

在设计拓扑结构时,始终在头脑中记着的一件重要事情就是消息的可靠性。当有无法处理的消息时,你就要决定该怎么办,以及作为一个整体的拓扑结构该做些什么。举个例子,在处理银行存款时,不要丢失任何事务报文就是很重要的事情。但是如果你要统计分析数以百万的tweeter消息,即使有一条丢失了,仍然可以认为你的结果是准确的。

对于Storm来说,根据每个拓扑的需要担保消息的可靠性是开发者的责任。这就涉及到消息可靠性和资源消耗之间的权衡。高可靠性的拓扑必须管理丢失的消息,必然消耗更多资源;可靠性较低的拓扑可能会丢失一些消息,占用的资源也相应更少。不论选择什么样的可靠性策略,Storm都提供了不同的工具来实现它。

要在spout中管理可靠性,你可以在分发时包含一个元组的消息ID(collector.emit(new Values(…),tupleId))。在一个元组被正确的处理时调用ack方法,而在失败时调用fail方法。当一个元组被所有的靶bolt和锚bolt处理过,即可判定元组处理成功(你将在第5章学到更多锚bolt知识)。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Storm入门之第四章Spouts


Storm入门之第三章拓扑

本文翻译自《Getting Started With Storm》  译者:吴京润   编辑:方腾飞

在这一章,你将学到如何在同一个Storm拓扑结构内的不同组件之间传递元组,以及如何向一个运行中的Storm集群发布一个拓扑。

数据流组

设计一个拓扑时,你要做的最重要的事情之一就是定义如何在各组件之间交换数据(数据流是如何被bolts消费的)。一个数据流组指定了每个bolt会消费哪些数据流,以及如何消费它们。

NOTE:一个节点能够发布一个以上的数据流,一个数据流组允许我们选择接收哪个。

数据流组在定义拓扑时设置,就像我们在第二章看到的:

···
    builder.setBolt("word-normalizer", new WordNormalizer())
           .shuffleGrouping("word-reader");
···

在前面的代码块里,一个boltTopologyBuilder对象设定, 然后使用随机数据流组指定数据源。数据流组通常将数据源组件的ID作为参数,取决于数据流组的类型不同还有其它可选参数。

NOTE:每个InputDeclarer可以有一个以上的数据源,而且每个数据源可以分到不同的组。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: Storm入门之第三章拓扑


JSR133中文版

原文链接  译文链接   翻译:丁一   下载:JSR133中文版 firefox_old_school_final

本文是JSR-133规范,即JavaTM内存模型与线程规范,由JSR-133专家组开发。本规范是JSR-176(定义了JavaTM平台 Tiger(5.0)发布版的主要特性)的一部分。本规范的标准内容将合并到JavaTM语言规范JavaTM虚拟机规范以及java.lang包的类说明中。本JSR-133规范将不再通过JCP维护和修改。未来所有对这些标准化内容的更新、修正以及说明都会出现在上述这些文档中。

本规范的标准化内容包含在第5, 7, 9.2, 9.3, 11, 12, 14, 15以及16节。其它章节,以及上述提到的章节的部分内容,属非标准化内容,用于解释和说明标准化内容。如果标准化内容和非标准化内容有冲突,以标准化内容为准。

本规范的讨论与开发异常复杂且专业性强,需要对一些学术论题有深刻的见解并了解它们的发展过程。这些讨论在JMM web站点上都有存档。该站点提供了额外的信息,可以帮助理解本规范形成的过程。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: JSR133中文版


如何合理地估算线程池大小?

感谢网友【蒋小强】投稿。

如何合理地估算线程池大小?

这个问题虽然看起来很小,却并不那么容易回答。大家如果有更好的方法欢迎赐教,先来一个天真的估算方法:假设要求一个系统的TPS(Transaction Per Second或者Task Per Second)至少为20,然后假设每个Transaction由一个线程完成,继续假设平均每个线程处理一个Transaction的时间为4s。那么问题转化为:

如何设计线程池大小,使得可以在1s内处理完20个Transaction?

计算过程很简单,每个线程的处理能力为0.25TPS,那么要达到20TPS,显然需要20/0.25=80个线程。

很显然这个估算方法很天真,因为它没有考虑到CPU数目。一般服务器的CPU核数为16或者32,如果有80个线程,那么肯定会带来太多不必要的线程上下文切换开销。
阅读全文

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 如何合理地估算线程池大小?


return top