并发编程网 - ifeve.com

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

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

数据流组

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

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

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

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

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

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

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

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

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

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

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

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

这个问题虽然看起来很小，却并不那么容易回答。大家如果有更好的方法欢迎赐教，先来一个天真的估算方法：假设要求一个系统的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个线程，那么肯定会带来太多不必要的线程上下文切换开销。
阅读全文

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

准备开始

在本章，我们要创建一个Storm工程和我们的第一个Storm拓扑结构。

NOTE: 下面假设你的JRE版本在1.6以上。我们推荐Oracle提供的JRE。你可以到http://www.java .com/downloads/下载。

操作模式

开始之前，有必要了解一下Storm的操作模式。有下面两种方式。

本地模式

在本地模式下，Storm拓扑结构运行在本地计算机的单一JVM进程上。这个模式用于开发、测试以及调试，因为这是观察所有组件如何协同工作的最简单方法。在这种模式下，我们可以调整参数，观察我们的拓扑结构如何在不同的Storm配置环境下运行。要在本地模式下运行，我们要下载Storm开发依赖，以便用来开发并测试我们的拓扑结构。我们创建了第一个Storm工程以后，很快就会明白如何使用本地模式了。

阅读全文

原文链接，译文链接，原文作者： Sarma Swaranga，本文最早发表于deepinmind，校对：郑旭东

这篇文章里我们主要讨论下如何在Java里实现一个对象池。最近几年，Java虚拟机的性能在各方面都得到了极大的提升，因此对大多数对象而言，已经没有必要通过对象池来提高性能了。根本的原因是，创建一个新的对象的开销已经不像过去那样昂贵了。

阅读全文

原书下载地址 译者：吴京润   编辑：方腾飞

译者注：本文翻译自《Getting Started With Storm》，本书中所有Storm相关术语都用斜体英文表示。 这些术语的字面意义翻译如下，由于这个工具的名字叫Storm，这些术语一律按照气象名词解释

• spout 龙卷，读取原始数据为bolt提供数据
• bolt 雷电，从spout或其它bolt接收数据，并处理数据，处理结果可作为其它bolt的数据源或最终结果
• nimbus 雨云，主节点的守护进程，负责为工作节点分发任务。

下面的术语跟气象就没有关系了

• topology 拓扑结构，Storm的一个任务单元
• define field(s) 定义域，由spout或bolt提供，被bolt接收

本文是该书的第一章。

基础知识

Storm是一个分布式的，可靠的，容错的数据流处理系统。它会把工作任务委托给不同类型的组件，每个组件负责处理一项简单特定的任务。Storm集群的输入流由一个被称作spout的组件管理，spout把数据传递给bolt， bolt要么把数据保存到某种存储器，要么把数据传递给其它的bolt。你可以想象一下，一个Storm集群就是在一连串的bolt之间转换spout传过来的数据。 阅读全文

原文链接 译文链接 翻译：踏雁寻花，校对：丁一

这里我将会给大家演示用ConcurrentHashMap类和lambda表达式实现一个本地缓存。因为Map有一个新的方法，在key为Null的时候自动计算一个新的value值。非常适合实现cache。来看下代码：

当然，这种方式很傻瓜。即使对于一个非常小的数，例如fibonacci(5)，上面的代码也会打印出很多行，而且都是在进行重复计算，输出如下（只截取一部分）：

阅读全文

以前分享的ppt，介绍了java7里的fork-join框架；

从slideshare下载，或从微盘下载

work-stealing在很多框架里都出现过，从两张图能大致看明白：

因最近hashmap误用引起的死循环又发生了一些案例，左耳朵浩子写了一篇blog 疫苗：Java HashMap的死循环，看了一下，大家的分析如出一辙。这篇blog也是好几年前写的了，之前在平台技术部的博客上贴过，随着组织结构的调整，那个博客可能不再维护，把这篇文章在这儿也保存一下。

李鹏同学在blog里写了篇关于HashMap死锁模拟的文章: http://blog.csdn.net/madding/archive/2010/08/25/5838477.aspx 做个纠正,那个不是死锁问题,而是死循环。

这个问题,我们以前讨论过。 校长之前的博客和淘宝的毕玄的《分布式Java应用:基础与实践》一书中都提到过 velocity导致cpu 100% 的bug,起因是HashMap的使用不当所致。

阅读全文

经过之前的铺垫，现在可以进入正题了。
我们关注的操作有：get，put，remove 这3个操作。

对于哈希表，Java中采用链表的方式来解决hash冲突的。
一个HashMap的数据结构看起来类似下图：

实现了同步的HashTable也是这样的结构，它的同步使用锁来保证的，并且所有同步操作使用的是同一个锁对象。这样若有n个线程同时在get时，这n个线程要串行的等待来获取锁。

阅读全文

原文是09年时写的，在公司的邮件列表发过，同事一粟 和清英 创建的并发编程网 对这方面概念和实战有更好的文章，贴出来仅供参考。pdf格式在：http://www.slideshare.net/hongjiang/concurrent-hashmap 可以获取

ConcurrentHashMap是Java5中新增加的一个线程安全的Map集合，可以用来替代HashTable。对于ConcurrentHashMap是如何提高其效率的，可能大多人只是知道它使用了多个锁代替HashTable中的单个锁，也就是锁分离技术（Lock Stripping）。实际上，ConcurrentHashMap对提高并发方面的优化，还有一些其它的技巧在里面（比如你是否知道在get操作的时候，它是否也使用了锁来保护？）。

我会试图用通俗一点的方法讲解一下 ConcurrentHashMap的实现方式，不过因为水平有限，在整理这篇文档的过程中，发现了更多自己未曾深入思考过的地方，使得我不得不从新调整了自己的讲解方式。我假设受众者大多是对Java存储模型(JMM)认识并不很深的（我本人也是）。如果我们不断的对ConcurrentHashMap中一些实现追问下去，最终还是要归到JMM层面甚至更底层的。这篇文章的关注点主要在同步方面，并不去分析HashMap中的一些数据结构方面的实现。

阅读全文

原文链接，译文连接，译者：梁海舰，校对：李任

注意，我将在这篇文章中说一些关于“无锁”和“无等待”算法的坏话。在我们开始之前，让我来问你一个问题：

你之前有过需要无锁算法来解决问题吗？为什么必须使用无锁算法来解决？
阅读全文

版权声明：本文为本作者原创文章，转载请注明出处。感谢 码梦为生| 刘锟洋 的投稿

今天看到 这篇文章：您还有心跳吗？超时机制分析   觉得挺有意思，有兴趣的同学可以先看看他的文章，简单记录了下自己的一个想法，无论好坏，权当参与讨论，共同进步吧。

Copy-On-Write简称COW，是一种用于程序设计中的优化策略。其基本思路是，从一开始大家都在共享同一个内容，当某个人想要修改这个内容的时候，才会真正把内容Copy出去形成一个新的内容然后再改，这是一种延时懒惰策略。从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,它们是CopyOnWriteArrayList和CopyOnWriteArraySet。CopyOnWrite容器非常有用，可以在非常多的并发场景中使用到。

什么是CopyOnWrite容器

CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

阅读全文

原文地址，译文地址，译者：李任，郑旭东 校对：蘑菇街-小宝

一个并发应用程序能及时执行的能力称为活跃性。本节将介绍最常见的活跃性问题：死锁（deadlock），以及另外两个活跃性问题：饥饿（starvation）和活锁（livelock）。

阅读全文