如果IT的历史，是以人为主体串接起来的话，那么肯定少不了Doug Lea。这个鼻梁挂着眼镜，留着德王威廉二世的胡子，脸上永远挂着谦逊腼腆笑容，服务于纽约州立大学Oswego分校计算机科学系的老大爷。
说他是这个世界上对Java影响力最大的个人，一点也不为过。因为两次Java历史上的大变革，他都间接或直接的扮演了举足轻重的角色。一次是由JDK 1.1到JDK 1.2，JDK1.2很重要的一项新创举就是Collections，其Collections的概念可以说承袭自Doug Lea于1995年发布的第一个被广泛应用的collections；一次是2004年所推出的Tiger。Tiger广纳了15项JSRs(Java Specification Requests)的语法及标准，其中一项便是JSR-166。JSR-166是来自于Doug编写的util.concurrent包。(摘自百度) 阅读全文
原文的下载地址：http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
中文版下载地址：深入理解并行编程V1.0 （4.1M）
本书是linux内核大牛paul的力作，和鲁阳同学一起，花了两个月时间进行翻译。
目前没有翻译问答部分，主要是时间不够，也担心不能将这部分翻译准确。
对内核深度发烧的同学可以看看。 阅读全文
原文地址：http://mechanical-sympathy.blogspot.com/2013/01/further-adventures-with-cas.html
In a previous article I reported what appeared to be a performance issue with CAS/LOCK instructions on the Sandy Bridge microarchitecture compared to the previous Nehalem microarchitecture. Since then I’ve worked with the good people of Intel to understand what was going on and I’m now pleased to be able to shine some light on the previous results.
I observed a small drop in throughput with the uncontended single-thread case, and an order-of-magnitude decrease in throughput once multiple threads contend when performing updates. This testing spawned out of observations testing Java Queue implementations and the Disruptor for the multi-producer case. I was initially puzzled by these findings because almost every other performance test I applied to Sandy Bridge indicated a major step forward for this microarchitecture. 阅读全文
原文链接 作者：Jakob Jenkov 译者：丁一
虽然许多同步器（如锁，信号量，阻塞队列等）功能上各不相同，但它们的内部设计上却差别不大。换句话说，它们内部的的基础部分是相同（或相似）的。了解这些基础部件能在设计同步器的时候给我们大大的帮助。这就是本文要细说的内容。
注：本文的内容是哥本哈根信息技术大学一个由Jakob Jenkov，Toke Johansen和Lars Bjørn参与的M.Sc.学生项目的部分成果。在此项目期间我们咨询Doug Lea是否知道类似的研究。有趣的是在开发Java 5并发工具包期间他已经提出了类似的结论。Doug Lea的研究，我相信，在《Java Concurrency in Practice》一书中有描述。这本书有一章“剖析同步器”就类似于本文，但不尽相同。
大部分同步器都是用来保护某个区域（临界区）的代码，这些代码可能会被多线程并发访问。要实现这个目标，同步器一般要支持下列功能：
并不是所有同步器都包含上述部分，也有些并不完全遵照上面的内容。但通常你能从中发现这些部分的一或多个。
原文地址 作者：Martin Thompson 译者：一粟 校对：无叶，方腾飞
本文我将和大家讨论并发编程中最基础的一项技术：内存屏障或内存栅栏，也就是让一个CPU处理单元中的内存状态对其它处理单元可见的一项技术。
CPU使用了很多优化技术来实现一个目标：CPU执行单元的速度要远超主存访问速度。在上一篇文章 “Write Combing （合并写）”中我已经介绍了其中的一项技术。CPU避免内存访问延迟最常见的技术是将指令管道化，然后尽量重排这些管道的执行以最大化利用缓存，从而把因为缓存未命中引起的延迟降到最小。
当一个程序执行时，只要最终的结果是一样的，指令是否被重排并不重要。例如，在一个循环里，如果循环体内没用到这个计数器，循环的计数器什么时候更新（在循环开始，中间还是最后）并不重要。编译器和CPU可以自由的重排指令以最佳的利用CPU，只要下一次循环前更新该计数器即可。并且在循环执行中，这个变量可能一直存在寄存器上，并没有被推到缓存或主存，这样这个变量对其他CPU来说一直都是不可见的。 阅读全文
原文地址 By Jakob Jenkov 翻译：寒桐 校对：方腾飞
阻塞队列与普通队列的区别在于，当队列是空的时，从队列中获取元素的操作将会被阻塞，或者当队列是满时，往队列里添加元素的操作会被阻塞。试图从空的阻塞队列中获取元素的线程将会被阻塞，直到其他的线程往空的队列插入新的元素。同样，试图往已满的阻塞队列中添加新元素的线程同样也会被阻塞，直到其他的线程使队列重新变得空闲起来，如从队列中移除一个或者多个元素，或者完全清空队列，下图展示了如何通过阻塞队列来合作：
原文地址 By Jakob Jenkov 翻译：寒桐 校对：方腾飞
Semaphore（信号量） 是一个线程同步结构，用于在线程间传递信号，以避免出现信号丢失（译者注：下文会具体介绍），或者像锁一样用于保护一个关键区域。自从5.0开始，jdk在java.util.concurrent包里提供了Semaphore 的官方实现，因此大家不需要自己去实现Semaphore。但是还是很有必要去熟悉如何使用Semaphore及其背后的原理 阅读全文
原文链接 作者：Dave 译者：卓二妹 校对：丁一
详细描述看Aleksey Shipilev这封邮件 —— 我们期待@Contended已久。JVM会自动为对象字段进行内存布局。通常JVM会这样做：(a)将对象的域按从大到小的顺序排列，以优化占用的空间；(b）打包引用类型的字段，以便垃圾收集器在追踪的时候能够处理相连的引用类型的字段。@Contended让程序能够更明确地控制并发和伪共享。通过该功能我们能够把那些频繁进行写操作的共享字段，从其它几乎是只读或只有少许写操作的字段中分离开来。原则很简单：对共享内容进行读操作的代价小，对共享内容的写操作代价非常高。我们也可以将那些可能会被同一个线程几乎同时写的字段打包到一起。
在高性能的计算中，我们常说缓存失效（cache-miss）是一个算法中最大性能损失点。 近些年来，我们的处理器处理能力的增长速度已经大大超过了访问主内存的延迟的缩短。 通过更宽的，多通道的总线，到主内存的带宽已经大大增加，但延迟并没有相应显著减少。 为了减少延迟，处理器采用愈加复杂的多层的高速缓存子系统。
在1994年的一篇论文“Hitting the memory wall: implications of the obvious”中描述了这个问题，并且认为由于缓存失效（cache-miss）必定存在，缓存不能最终解决这个问题。我的目标是：向大家展示通过利用访问模型，它是对缓存层次结构的思考，上面的结论并不是必然的。
让我们带着问题，来看下面的例子， 我们的硬件试图通过一些技术来减少主内存的延迟。 内存访问模型主要基于下面三个规律：
1、时间局部性 ：最近访问过的内存最可能立马再次被访问；
2、空间局部性：相邻的内存最可能立马再次被访问；
3、 跨越式：内存访问可能会遵循一种可预测的模式。
阅读全文
Mechanical Sympathy（需要翻墙才能访问）是Martin Thompson的博客，这个博客主要讲的是底层硬件是如何运作的，以及如何编程能够与地层硬件良好的协作。英文名称的为未翻译的文章，有兴趣的同学可以领取翻译。
原文链接 作者：Jakob Jenkov 译者：余绍亮 校对：丁一
所谓Slipped conditions，就是说， 从一个线程检查某一特定条件到该线程操作此条件期间，这个条件已经被其它线程改变，导致第一个线程在该条件上执行了错误的操作。这里有一个简单的例子：
[code lang=”java”]
public class Lock {
private boolean isLocked = true;
public void lock(){
synchronized(this){
while(isLocked){
try{
this.wait();
} catch(InterruptedException e){
//do nothing, keep waiting
}
}
}
synchronized(this){
isLocked = true;
}
}
public synchronized void unlock(){
isLocked = false;
this.notify();
}
}
[/code]
阅读全文
原文地址 作者：Mechanical Sympathy 译者：潘曦 校对：Simon-SZ ，方腾飞
即使是资深的技术人员，我经常听到他们谈论某些操作是如何导致一个CPU缓存的刷新。看来这是关于CPU缓存如何工作和缓存子系统如何与执行核心交互的一个常见误区。本文将致力于解释CPU缓存的功能以及执行程序指令的CPU核心如何与缓存交互。我将以最新的Intel x86 CPU为例进行说明，其他CPU也使用相似技术以达到相同目的。
绝大部分常见的现代系统都被设计成在多处理器上共享内存。共享内存的系统都有一个单独的内存资源，它会被两个或者更多的独立CPU核心同时访问。核心到主存的延迟变化范围很大，大约在10-100纳秒。在100ns内，一个3GH的CPU可以处理多达1200条指令。每一个Sandy Bridge的CPU核心，在每个CPU时钟内可以并行处理4条指令。CPU使用缓存子系统避免了处理核心直接访问主存的延迟，这样能使CPU更高效的处理指令。一些缓存很小、非常快速并且集成在每个核心之内；而另一些则慢一些、更大、在各个核心间共享。这些缓存与寄存器和主内存一起构成了非持久性的内存体系。 阅读全文
原文地址：http://mechanical-sympathy.blogspot.com/2012/08/memory-access-patterns-are-important.html（因墙转载）
In high-performance computing it is often said that the cost of a cache-miss is the largest performance penalty for an algorithm. For many years the increase in speed of our processors has greatly outstripped latency gains to main-memory. Bandwidth to main-memory has greatly increased via wider, and multi-channel, buses however the latency has not significantly reduced. To hide this latency our processors employ evermore complex cache sub-systems that have many layers.
The 1994 paper “Hitting the memory wall: implications of the obvious” describes the problem and goes on to argue that caches do not ultimately help because of compulsory cache-misses. I aim to show that by using access patterns which display consideration for the cache hierarchy, this conclusion is not inevitable.
阅读全文
原文链接 译者：章筱虎 校对：方腾飞
Java线程类也是一个object类,它的实例都继承自java.lang.Thread或其子类。 可以用如下方式用java中创建一个线程：
[code lang=”java”]
Tread thread = new Thread();
[/code]
执行该线程可以调用该线程的start()方法:
[code lang=”java”]
thread.start();
[/code]
(24 votes, average: 3.75 out of 5)
Loading...
