Java中的锁
原文链接 作者:Jakob Jenkov 译者:申章 校对:丁一
锁像synchronized同步块一样,是一种线程同步机制,但比Java中的synchronized同步块更复杂。因为锁(以及其它更高级的线程同步机制)是由synchronized同步块的方式实现的,所以我们还不能完全摆脱synchronized关键字(译者注:这说的是Java 5之前的情况)。
自Java 5开始,java.util.concurrent.locks包中包含了一些锁的实现,因此你不用去实现自己的锁了。但是你仍然需要去了解怎样使用这些锁,且了解这些实现背后的理论也是很有用处的。可以参考我对java.util.concurrent.locks.Lock的介绍,以了解更多关于锁的信息。
以下是本文所涵盖的主题:
竞态条件与临界区
原文链接 作者:Jakob Jenkov 译者:He Jianjun 校对:丁一
在同一程序中运行多个线程本身不会导致问题,问题在于多个线程访问了相同的资源。如,同一内存区(变量,数组,或对象)、系统(数据库,web services等)或文件。实际上,这些问题只有在一或多个线程向这些资源做了写操作时才有可能发生,只要资源没有发生变化,多个线程读取相同的资源就是安全的。
并发译文翻译计划(三)
为了促进并发编程在中国的推广和研究,让更多的同学能阅读到国外的文献。所以打算将国外的编程文献翻译成中文,但是我一个人的精力有限,所以希望征集译者帮忙一起翻译。这是一篇比较基础的文章,希望翻译后对新手有很大帮助。
- Introduction to Java Concurrency(译者:jiyou)
- Benefits (译者:古圣昌)
- Costs (译者:古圣昌)
- Creating and Starting Threads(译者:阿里-章筱虎)
- Race Conditions and Critical Sections(译者:He Jianjun,已完成)
- Thread Safety and Shared Resources(译者:Bi Ran,已完成)
- Thread Safety and Immutability(译者:高嵩,已完成)
- Synchronized Blocks (译者:同杰)
- Thread Signaling (译者:杜建雄)
- Deadlock (译者:申章)
- Deadlock Prevention (译者:申章)
- Starvation and Fairness (译者: jiyou)
- Nested Monitor Lockout(译者:柳暗 ☆花明)
- Slipped Conditions(译者:柳暗 ☆花明)
- Locks (译者:申章)
- Read / Write Locks(译者:华)
- Reentrance Lockout(译者:刘晓日)
- Semaphores (译者:寒桐)
- Blocking Queues (译者:寒桐)
- Thread Pools (译者:长源)
- Anatomy of a Synchronizer(译者:高嵩)
有兴趣的同学可以一起参与。 阅读全文
从Java视角理解系统结构(一)CPU上下文切换
作者:Minzhou 本文是从Java视角理解系统结构连载文章
在高性能编程时,经常接触到多线程. 起初我们的理解是, 多个线程并行地执行总比单个线程要快, 就像多个人一起干活总比一个人干要快. 然而实际情况是, 多线程之间需要竞争IO设备, 或者竞争锁资源,导致往往执行速度还不如单个线程. 在这里有一个经常提及的概念就是: 上下文切换(Context Switch).
上下文切换的精确定义可以参考: http://www.linfo.org/context_switch.html。下面做个简单的介绍. 多任务系统往往需要同时执行多道作业.作业数往往大于机器的CPU数, 然而一颗CPU同时只能执行一项任务, 如何让用户感觉这些任务正在同时进行呢? 操作系统的设计者巧妙地利用了时间片轮转的方式, CPU给每个任务都服务一定的时间, 然后把当前任务的状态保存下来, 在加载下一任务的状态后, 继续服务下一任务. 任务的状态保存及再加载, 这段过程就叫做上下文切换. 时间片轮转的方式使多个任务在同一颗CPU上执行变成了可能, 但同时也带来了保存现场和加载现场的直接消耗。
阅读全文
Sharing Data Among Threads Without Contention
原文地址:http://www.oraclejavamagazine-digital.com/javamagazine/20120304/?pg=56&pm=1&u1=friend 作者 Trisha
The London Multi-Asset Exchange (LMAX) Disruptor is an open source concurrency framework that recently won the 2011 Duke’s Choice Award for Innovative Programming Framework. In this article, I use diagrams to describe what the Disruptor is; what it does; and, to some extent, how it works.
线程间共享数据无需竞争
原文 地址 作者 Trisha 译者:李同杰
LMAX Disruptor 是一个开源的并发框架,并获得2011 Duke’s 程序框架创新奖。本文将用图表的方式为大家介绍Disruptor是什么,用来做什么,以及简单介绍背后的实现原理。
Disruptor是什么?
Disruptor 是线程内通信框架,用于线程里共享数据。LMAX 创建Disruptor作为可靠消息架构的一部分并将它设计成一种在不同组件中共享数据非常快的方法。
基于Mechanical Sympathy(对于计算机底层硬件的理解),基本的计算机科学以及领域驱动设计,Disruptor已经发展成为一个帮助开发人员解决很多繁琐并发编程问题的框架。
很多架构都普遍使用一个队列共享线程间的数据(即传送消息)。图1 展示了一个在不同的阶段中通过使用队列来传送消息的例子(每个蓝色的圈代表一个线程)。 阅读全文
阿里内贸团队敏捷实践(一)如何打造合作型团队
本文是作者原创, 原文发表于程序员2013年2月刊 http://www.programmer.com.cn/15217/ 转载请注明出处
本文中,来自阿里内贸团队的工程师分享了所在团队打造合作型“精英”小团队的敏捷实践方法,同时讲述了实践的效果,旨在给大家一些启发,以供参考和借鉴。
能打造出Facebook里所提倡的“精英团队”固然非常好,但这样会对团队中的每位成员都有较高的要求。我所在的团队希望通过将团队合 作精神运用在项目的各个阶段来打造出一支强有力的合作型小团队,并且取得了很不错的战绩:每两周发布一个版本,完成了几次零Bug的项目,实现了一年线上 零故障。
我们团队由2名产品经理、6名开发人员和2名QA组成,并根据团队特点量身定制了一套敏捷的开发方式。本文主要分享在需求、设计、开发和总结等阶段中如何提高团队成员的合作意识,从而形成团队合力的最佳实践。
什么是上下文切换
原文:http://www.wisegeek.com/what-is-context-switching.htm 译者:郭蕾 校对:方腾飞
支持多任务处理是CPU设计史上最大的跨越之一。在计算机中,多任务处理是指同时运行两个或多个程序。从使用者的角度来看,这看起来并不复杂或者难以实现,但是它确实是计算机设计史上一次大的飞跃。在多任务处理系统中,CPU需要处理所有程序的操作,当用户来回切换它们时,需要记录这些程序执行到哪里。上下文切换就是这样一个过程,他允许CPU记录并恢复各种正在运行程序的状态,使它能够完成切换操作。 阅读全文
聊聊我对Java内存模型的理解
所有的编程语言中都有内存模型这个概念,区别于微架构的内存模型,高级语言的内存模型包括了编译器和微架构两部分。我试图了解了Java、C#和Go语言的内存模型,发现内容基本大同小异,只是这些语言在具体实现的时候略有不同。
我们来看看Java内存模型吧,提到Java内存模型大家对这个图一定非常熟悉: 阅读全文
Java 7与伪共享的新仇旧恨
原文:False Shareing && Java 7 (依然是马丁的博客) 译者:杨帆 校对:方腾飞
在我前一篇有关伪共享的博文中,我提到了可以加入闲置的long字段来填充缓存行来避免伪共享。但是看起来Java 7变得更加智慧了,它淘汰或者是重新排列了无用的字段,这样我们之前的办法在Java 7下就不奏效了,但是伪共享依然会发生。我在不同的平台上实验了一些列不同的方案,并且最终发现下面的代码是最可靠的。(译者注:下面的是最终版本,马丁在大家的帮助下修改了几次代码) 阅读全文
False Sharing && Java 7
原文:http://mechanical-sympathy.blogspot.hk/2011/08/false-sharing-java-7.html (因为被墙移动到墙内)
In my previous post on False Sharing I suggested it can be avoided by padding the cache line with unused longfields. It seems Java 7 got clever and eliminated or re-ordered the unused fields, thus re-introducing false sharing. I’ve experimented with a number of techniques on different platforms and found the following code to be the most reliable.