Java开发人员

Java开发人员的十大戒律

文章分类:IT生活

对Java开发者来说，有许多的标准和最佳实践。本文列举了每一个开发人员必须遵从的十大基本法则；如果有了可以遵从的规则而不遵从，那么将导致的是十分悲惨的结局。

1． 在你的代码里加入注释
每个人都知道这点，但不知何故忘记了遵守。算一算有多少次你“忘记”了添加注释？这是事实：注释对程序在功能上没有实质的贡献。但是，你需要一次又一次的回到你两个礼拜之前写的代码上来，可能一辈子都是这样，你一定记不住这些代码为什么会这样。如果这些代码是你的，你还比较的幸运。因为它有可能让你回忆起。但是不幸的是，很多时间，这些代码是别人的，而且很有可能他已经离开了公司。
好程序员写的代码本身就是注释

2． 不要让事情复杂化
我以前就这么干过，而且我相信所有的人都这么干过。开发人员常常为一个简单的问题而提出一个解决方案。我们为仅仅只有5个用户的应用而引入EJBs。我们为一个应用使用框架而它根本不需要。我们加入属性文件，面向对象的解决方案，和线程到应用中，但是它根本不需要这些。为什么我们这样做？我们中的一些人是因为不知道怎么做更好，但是还有一些人这样做的目的是为了学习新的知识，从而使得这个应用对于我们自己来说做得比较有趣。

3． 牢牢记住——“少即是多（less is more）”并不永远是好的
代码的效率是一伟大的事情，但是在很多情况下，写更少的代码行并不能提高该代码的效率。请让我向你展示一个简单的例子。

if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0)) ||
(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))){
newStatusCode = "NYP";
}[
/code]
我想问一句：说出上面的那段代码的if条件想干什么容易吗？现在，我们再来假设无论是谁写出这段代码，而没有遵从第一条规则——在你的代码里加入注释。
如果我们把这个条件分到两个独立的if陈述句中，难道不是更简单一些吗？现在，考虑下面的修正代码：

Java代码

1. if(newStatusCode.equals("SD") && (sellOffDate == null ||   
2. todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&   
3. todayDate.compareTo(lastUsedDate)>0))){   
4. newStatusCode = "NYP";   
5. }else  
6. if(newStatusCode.equals("OBS") && (OBSDate == null ||   
7. todayDate.compareTo(OBSDate)<0))   
8. {   
9. newStatusCode = "NYP";   
10. }  

if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0))){
newStatusCode = "NYP";
}else
if(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))
{
newStatusCode = "NYP";
}

难道它不是有了更好的可读性？是的，我们重复了陈述条件。是的，我们多出了一个多余的“IF”和两对多余的括弧。但是代码有了更好的可读性和可理解性。

4． 请不要有硬代码
开发人员常常有意识的忘记或者忽视这条规则，原因是我们，和一般时候一样，在赶时间。如果我们遵从这条规则，我们可能会赶不上进度。我们可能不能结束我们的当前状态。但是写一条额外的定义静态常量的代码行又能花费我们多少时间呢？
这里有一个例子。

Java代码

1. public class A {   
2.   
3. public static final String S_CONSTANT_ABC = "ABC";   
4.   
5. public boolean methodA(String sParam1){   
6. if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){   
7. return true;   
8. }   
9. return false;   
10. }   
11. }  

public class A {

public static final String S_CONSTANT_ABC = "ABC";

public boolean methodA(String sParam1){
if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true;
}
return false;
}
}

现在，每一次我们需要和某一些变量比较字符串“ABC”的时候，我们只需要引用S_CONSTANT_ABC，而不是记住实际的代码是什么。它还有一个好处是：更加容易在一个地方修改常量，而不是在所有的代码中寻找这个代码

5.不要发明你自己的frameworks
已经推出了几千种frameworks，而且它们中的大多数是开源的。这些frameworks中间有很多是极好的解决方案，被应用到成千上万的应用中。你们需要跟上这些新frameworks的步伐，最起码是肤浅的。在这些极好的、应用广泛的frameworks中间，一个最好的、最直接的例子是 Struts。在你所能想象到的frameworks中，这个开源的web frameworks对于基于web的应用是一个完美的候选者。但是你必须记住第二条规则——不要让事情复杂化。如果你开发的应用只有三个页面—请，不要使用Struts，对于这样一个应用，没有什么“控制”请求的。

6． 不要打印行和字符串相加
我知道，为了调试的目的，开发人员喜欢在每一个我们认为适合的地方添加System.out.println，而且我们会对我们自己说，会在以后删掉这些代码的。但是我们常常忘掉删去这些代码行，或者我们根本就不想删掉它们。我们使用System.out.println来测试，当我们测试完成以后，为什么我们还能接触到它们呢？我们可能删掉一行我们实际需要的代码，仅仅是因为你低估了System.out.println所带来的伤害，考虑下面的代码：

Java代码

1. public class BadCode {   
2. public static void calculationWithPrint(){   
3. double someValue = 0D;   
4. for (int i = 0; i < 10000; i++) {   
5. System.out.println(someValue = someValue + i);   
6. }   
7. }   
8. public static void calculationWithOutPrint(){   
9.   
10. double someValue = 0D;   
11. for (int i = 0; i < 10000; i++) {   
12. someValue = someValue + i;   
13. }   
14.   
15. }   
16. public static void main(String [] n) {   
17. BadCode.calculationWithPrint();   
18. BadCode.calculationWithOutPrint();   
19. }   
20. }  

public class BadCode {
public static void calculationWithPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
System.out.println(someValue = someValue + i);
}
}
public static void calculationWithOutPrint(){

double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
}

}
public static void main(String [] n) {
BadCode.calculationWithPrint();
BadCode.calculationWithOutPrint();
}
}

根据测试,calculationWithOutPrint()方法的运行花了0.001204秒。相比较而言，运行calculationWithPrint()方法花了令人惊讶的10.52秒。

（如果你不知道怎么得到一个像这样的表格，请参阅我的文章“Java Profiling with WSAD” Java Profiling with WSAD）
避免这样一个CPU浪费的最好方法是引入一个包装器方法，就象下面这样

Java代码

1. public class BadCode {   
2.   
3. public static final int DEBUG_MODE = 1;   
4. public static final int PRODUCTION_MODE = 2;   
5.   
6. public static void calculationWithPrint(int logMode){   
7. double someValue = 0D;   
8. for (int i = 0; i < 10000; i++) {   
9. someValue = someValue + i;   
10. myPrintMethod(logMode, someValue);   
11. }   
12. }   
13.   
14. public static void myPrintMethod(int logMode, double value) {   
15.   
16.   
17. if (logMode > BadCode.DEBUG_MODE) { return; }   
18.   
19.   
20. System.out.println(value);   
21. }   
22. public static void main(String [] n) {   
23. BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE);   
24. }   
25. }  

public class BadCode {

public static final int DEBUG_MODE = 1;
public static final int PRODUCTION_MODE = 2;

public static void calculationWithPrint(int logMode){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
myPrintMethod(logMode, someValue);
}
}

public static void myPrintMethod(int logMode, double value) {


if (logMode > BadCode.DEBUG_MODE) { return; }


System.out.println(value);
}
public static void main(String [] n) {
BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE);
}
}

根据测试，使用了StringBuffer的那个方法只花了0.01秒来执行，而那个使用了字符串相加的方法却花了0.08秒来运行。选择是显而易见的。

7． 关注GUI
不管这听起来有多么可笑，我都要再三地说明：GUI对于商业客户来说和功能和性能一样重要。GUI是一个成功的系统的必要的一部分。（但是），IT杂志常常倾向于忽视GUI的重要性。很多机构为了省钱而不雇用那些在设计“用户友好”GUI方面有丰富经验的设计人员。Java开发人员不得不依赖他们自己的 HTML知识，但是他们在这方面的知识十分有限。我看到过很多这样的应用：它们是“计算机友好”，而不是“用户友好”我很少很少能看到有开发人员既精通软件开发，又精通GUI开发。如果你是那个不幸的开发人员，被分配去开发用户接口，你应该遵从以下的三条原则：
一、不要重复发明轮子。寻找有相似用户接口需求的已经存在的系统。
二、首先创建一个原型。这是非常重要的步骤。客户喜欢看看他们将要得到什么。这对你来说也是很好的，因为在你全力以赴而做出一个将要使用户生气的用户接口之前，你就得到了它们的反馈。
三、戴用户的帽子。换一句话说，站在用户的视角检查应用的需求。例如，一个总结页面到底要不要分页。作为一个软件开发者，你倾向于在一个系统中忽视分页，因为这样使得你有比较少的开发复杂性。但是，这对于从一个用户的视角来说却不是最好的解决方案，因为小结的数据将会有成百上千个数据行。

8． 永远准备文档化的需求
每一个业务需求都必须文档化。这可能在一些童话故事里才能成真，但是在现实世界却不可能。不管时间对于你的开发来说是多么紧迫，也不管交付日期马上就要到来，你永远都必须清楚，每一个业务需求是文档化的。

9． 单元测试、单元测试、单元测试
我将不会深入地讨论哪些什么是把你的代码进行单元测试的最佳方法的细节问题。我将要说的是单元测试必须要做。这是编程的最基本的法则。这是上面所有法则中最不能被忽略的一个。如果你的同事能为你的代码创建和测试单元测试，这是最好不过的事。但是如果没有人为你做这些事，那么你就必须自己做。在创建你的单元测试计划的时候，遵从下面的这些规则：
一、在写代码之前就写单元测试用例。
二、在单元测试里写注释。
三、测试一切执行“interesting”功能的公有方法（“interesting”的意思是非setters或getters方法，除非它们通过一种特殊的方式执行set和get方法）。

10． 记住—质量，而不是数量。
不要在办公室里呆得太晚（当你不必呆的太晚的时候）。我理解有时，产品的问题、紧迫的最终期限、意想不到的事件都会阻止我们按时下班。但是，在正常情况下，经理是不会赏识和奖赏那些下班太晚的员工的，他赏识他们是因为他们所做产品的质量。如果你遵从了我上面给出的那些规则，你将会发现你的代码更加少的 bug，更加多的可维护性。而这才是你的工作的最重要的部分。
比尔盖茨说：用代码行来评价软件就如同用质量来评价一架飞机。

总结
在这篇文章里，我给出了针对Java开发人员的十个重要的规则。重要的不仅仅是知道这些规则，在编码的过程中遵从这些规则更为重要。希望这些规则能够帮助我们成为更好的编程人员和专业人员。

• 14:22
• 浏览 (28)
• 评论 (0)
• 分类: Java基础
• 收藏

2010 - 09 - 19

缩略显示

成为编程高手的八大奥秘

文章分类:IT生活

    不知不觉做软件已经做了十年，有成功的喜悦，也有失败的痛苦，但总不敢称自己是高手，因为和我心目中真正的高手们比起来，还差的太远。世界上并没有成为高手的捷径，但一些基本原则是可以遵循的。

　　 1. 扎实的基础。数据结构、离散数学、编译原理，这些是所有计算机科学的基础，如果不掌握他们，很难写出高水平的程序。据我的观察，学计算机专业的人比学其他专业的人更能写出高质量的软件。程序人人都会写，但当你发现写到一定程度很难再提高的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP，即使你再精通OOP，遇到一些基本算法的时候可能也会束手无策。

　　 2. 丰富的想象力。不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问题的方案，试试别人从没想过的方法。丰富的想象力是建立在丰富的知识的基础上，除计算机以外，多涉猎其他的学科，比如天文、物理、数学等等。另外，多看科幻电影也是一个很好的途径。

　　 3. 最简单的是最好的。这也许是所有科学都遵循的一条准则，如此复杂的质能互换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc2。简单的方法更容易被人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单方案不能满足要求时再考虑复杂的方案。

　　 4. 不钻牛角尖。当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听轻音乐，和朋友聊聊天。当我遇到难题的时候会去玩游戏，而且是那种极暴力的打斗类游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责编程的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候，我会发现那些难题现在竟然可以迎刃而解。

　　 5. 对答案的渴求。人类自然科学的发展史就是一个渴求得到答案的过程，即使只能知道答案的一小部分也值得我们去付出。只要你坚定信念，一定要找到问题的答案，你才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。

　　 6. 多与别人交流。三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花。多上上网，看看别人对同一问题的看法，会给你很大的启发。

　　 7. 良好的编程风格。注意养成良好的习惯，代码的缩进编排，变量的命名规则要始终保持一致。大家都知道如何排除代码中错误，却往往忽视了对注释的排错。注释是程序的一个重要组成部分，它可以使你的代码更容易理解，而如果代码已经清楚地表达了你的思想，就不必再加注释了，如果注释和代码不一致，那就更加糟糕。

　　 8. 韧性和毅力。这也许是"高手"和一般程序员最大的区别。A good programming is 99 weat and 1?offee。高手们并不是天才，他们是在无数个日日夜夜中磨练出来的。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个 10000以内的素数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一工作，你就可以满足这一条。

　　这些是我这几年程序员生涯的一点体会，希望能够给大家有所帮助。
   作者：金蝶中间件公司CTO袁红岗

• 14:16
• 浏览 (29)
• 评论 (0)
• 分类: Java基础
• 收藏

2010 - 09 - 19

缩略显示

Volatile的使用与线程安全

文章分类:Java编程

关键字：volatile,synchronized,作用,例子,多线程

    Java™ 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量。这两种机制的提出都是为了实现代码线程的安全性。其中 Volatile 变量的同步性较差（但有时它更简单并且开销更低），而且其使用也更容易出错。在这期的 Java 理论与实践中，Brian Goetz 将介绍几种正确使用 volatile 变量的模式，并针对其适用性限制提出一些建议。

Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。

锁提供了两种主要特性：互斥（mutual exclusion）和可见性（visibility）。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。

Volatile 变量
Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）。

出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。

正确使用 volatile 变量的条件
您只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：
    * 对变量的写操作不依赖于当前值。
    * 该变量没有包含在具有其他变量的不变式中。

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

第一个条件的限制使 volatile 变量不能用作线程安全计数器。虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由读取－修改－写入操作序列组成的组合操作，必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操作需要使 x 的值在操作期间保持不变，而 volatile 变量无法实现这点。（然而，如果将值调整为只从单个线程写入，那么可以忽略第一个条件。）

大多数编程情形都会与这两个条件的其中之一冲突，使得 volatile 变量不能像 synchronized 那样普遍适用于实现线程安全。清单 1 显示了一个非线程安全的数值范围类。它包含了一个不变式 —— 下界总是小于或等于上界。

清单 1. 非线程安全的数值范围类

Java代码

1. @NotThreadSafe  
2. public class NumberRange {   
3.     private int lower, upper;   
4.   
5.     public int getLower() { return lower; }   
6.     public int getUpper() { return upper; }   
7.   
8.     public void setLower(int value) {   
9.         if (value > upper)   
10.             throw new IllegalArgumentException(...);   
11.         lower = value;   
12.     }   
13.   
14.     public void setUpper(int value) {   
15.         if (value < lower)   
16.             throw new IllegalArgumentException(...);   
17.         upper = value;   
18.     }   
19. }  

@NotThreadSafe
public class NumberRange {
    private int lower, upper;

    public int getLower() { return lower; }
    public int getUpper() { return upper; }

    public void setLower(int value) {
        if (value > upper)
            throw new IllegalArgumentException(...);
        lower = value;
    }

    public void setUpper(int value) {
        if (value < lower)
            throw new IllegalArgumentException(...);
        upper = value;
    }
}

这种方式限制了范围的状态变量，因此将 lower 和 upper 字段定义为 volatile 类型不能够充分实现类的线程安全；从而仍然需要使用同步。否则，如果凑巧两个线程在同一时间使用不一致的值执行 setLower 和 setUpper 的话，则会使范围处于不一致的状态。例如，如果初始状态是 (0, 5)，同一时间内，线程 A 调用 setLower(4) 并且线程 B 调用 setUpper(3)，显然这两个操作交叉存入的值是不符合条件的，那么两个线程都会通过用于保护不变式的检查，使得最后的范围值是 (4, 3) —— 一个无效值。至于针对范围的其他操作，我们需要使 setLower() 和 setUpper() 操作原子化 —— 而将字段定义为 volatile 类型是无法实现这一目的的。

性能考虑
使用 volatile 变量的主要原因是其简易性：在某些情形下，使用 volatile 变量要比使用相应的锁简单得多。使用 volatile 变量次要原因是其性能：某些情况下，volatile 变量同步机制的性能要优于锁。

很难做出准确、全面的评价，例如 “X 总是比 Y 快”，尤其是对 JVM 内在的操作而言。（例如，某些情况下 VM 也许能够完全删除锁机制，这使得我们难以抽象地比较 volatile 和 synchronized 的开销。）就是说，在目前大多数的处理器架构上，volatile 读操作开销非常低 —— 几乎和非 volatile 读操作一样。而 volatile 写操作的开销要比非 volatile 写操作多很多，因为要保证可见性需要实现内存界定（Memory Fence），即便如此，volatile 的总开销仍然要比锁获取低。

volatile 操作不会像锁一样造成阻塞，因此，在能够安全使用 volatile 的情况下，volatile 可以提供一些优于锁的可伸缩特性。如果读操作的次数要远远超过写操作，与锁相比，volatile 变量通常能够减少同步的性能开销。

正确使用 volatile 的模式
很多并发性专家事实上往往引导用户远离 volatile 变量，因为使用它们要比使用锁更加容易出错。然而，如果谨慎地遵循一些良好定义的模式，就能够在很多场合内安全地使用 volatile 变量。要始终牢记使用 volatile 的限制 —— 只有在状态真正独立于程序内其他内容时才能使用 volatile —— 这条规则能够避免将这些模式扩展到不安全的用例。

模式 #1：状态标志
也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

很多应用程序包含了一种控制结构，形式为 “在还没有准备好停止程序时再执行一些工作”，如清单 2 所示：

清单 2. 将 volatile 变量作为状态标志使用

Java代码

1. volatile boolean shutdownRequested;   
2.   
3. ...   
4.   
5. public void shutdown() { shutdownRequested = true; }   
6.   
7. public void doWork() {   
8.     while (!shutdownRequested) {   
9.         // do stuff   
10.     }   
11. }  

volatile boolean shutdownRequested;

...

public void shutdown() { shutdownRequested = true; }

public void doWork() {
    while (!shutdownRequested) {
        // do stuff
    }
}

很可能会从循环外部调用 shutdown() 方法 —— 即在另一个线程中 —— 因此，需要执行某种同步来确保正确实现 shutdownRequested 变量的可见性。（可能会从 JMX 侦听程序、GUI 事件线程中的操作侦听程序、通过 RMI 、通过一个 Web 服务等调用）。然而，使用 synchronized 块编写循环要比使用清单 2 所示的 volatile 状态标志编写麻烦很多。由于 volatile 简化了编码，并且状态标志并不依赖于程序内任何其他状态，因此此处非常适合使用 volatile。

这种类型的状态标记的一个公共特性是：通常只有一种状态转换；shutdownRequested 标志从 false 转换为 true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从 false 到 true，再转换到 false）。此外，还需要某些原子状态转换机制，例如原子变量。

模式 #2：一次性安全发布（one-time safe publication）
缺乏同步会导致无法实现可见性，这使得确定何时写入对象引用而不是原语值变得更加困难。在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。（这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象）。

实现安全发布对象的一种技术就是将对象引用定义为 volatile 类型。清单 3 展示了一个示例，其中后台线程在启动阶段从数据库加载一些数据。其他代码在能够利用这些数据时，在使用之前将检查这些数据是否曾经发布过。

清单 3. 将 volatile 变量用于一次性安全发布

Java代码

1. public class BackgroundFloobleLoader {   
2.     public volatile Flooble theFlooble;   
3.   
4.     public void initInBackground() {   
5.         // do lots of stuff   
6.         theFlooble = new Flooble();  // this is the only write to theFlooble   
7.     }   
8. }   
9.   
10. public class SomeOtherClass {   
11.     public void doWork() {   
12.         while (true) {   
13.             // do some stuff...   
14.             // use the Flooble, but only if it is ready   
15.             if (floobleLoader.theFlooble != null)   
16.                 doSomething(floobleLoader.theFlooble);   
17.         }   
18.     }   
19. }  

public class BackgroundFloobleLoader {
    public volatile Flooble theFlooble;

    public void initInBackground() {
        // do lots of stuff
        theFlooble = new Flooble();  // this is the only write to theFlooble
    }
}

public class SomeOtherClass {
    public void doWork() {
        while (true) {
            // do some stuff...
            // use the Flooble, but only if it is ready
            if (floobleLoader.theFlooble != null)
                doSomething(floobleLoader.theFlooble);
        }
    }
}

如果 theFlooble 引用不是 volatile 类型，doWork() 中的代码在解除对 theFlooble 的引用时，将会得到一个不完全构造的 Flooble。

该模式的一个必要条件是：被发布的对象必须是线程安全的，或者是有效的不可变对象（有效不可变意味着对象的状态在发布之后永远不会被修改）。volatile 类型的引用可以确保对象的发布形式的可见性，但是如果对象的状态在发布后将发生更改，那么就需要额外的同步。

模式 #3：独立观察（independent observation）
安全使用 volatile 的另一种简单模式是：定期 “发布” 观察结果供程序内部使用。例如，假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。

使用该模式的另一种应用程序就是收集程序的统计信息。清单 4 展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用 lastUser 引用来发布值，以供程序的其他部分使用。
清单 4. 将 volatile 变量用于多个独立观察结果的发布

Java代码

1. public class UserManager {   
2.     public volatile String lastUser;   
3.   
4.     public boolean authenticate(String user, String password) {   
5.         boolean valid = passwordIsValid(user, password);   
6.         if (valid) {   
7.             User u = new User();   
8.             activeUsers.add(u);   
9.             lastUser = user;   
10.         }   
11.         return valid;   
12.     }   
13. }  

public class UserManager {
    public volatile String lastUser;

    public boolean authenticate(String user, String password) {
        boolean valid = passwordIsValid(user, password);
        if (valid) {
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
}

该模式是前面模式的扩展；将某个值发布以在程序内的其他地方使用，但是与一次性事件的发布不同，这是一系列独立事件。这个模式要求被发布的值是有效不可变的 —— 即值的状态在发布后不会更改。使用该值的代码需要清楚该值可能随时发生变化。

模式 #4：“volatile bean” 模式
volatile bean 模式适用于将 JavaBeans 作为“荣誉结构”使用的框架。在 volatile bean 模式中，JavaBean 被用作一组具有 getter 和/或 setter 方法 的独立属性的容器。volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。

在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通 —— 除了获取或设置相应的属性外，不能包含任何逻辑。此外，对于对象引用的数据成员，引用的对象必须是有效不可变的。（这将禁止具有数组值的属性，因为当数组引用被声明为 volatile 时，只有引用而不是数组本身具有 volatile 语义）。对于任何 volatile 变量，不变式或约束都不能包含 JavaBean 属性。清单 5 中的示例展示了遵守 volatile bean 模式的 JavaBean：

清单 5. 遵守 volatile bean 模式的 Person 对象

Java代码

1. @ThreadSafe  
2. public class Person {   
3.     private volatile String firstName;   
4.     private volatile String lastName;   
5.     private volatile int age;   
6.   
7.     public String getFirstName() { return firstName; }   
8.     public String getLastName() { return lastName; }   
9.     public int getAge() { return age; }   
10.   
11.     public void setFirstName(String firstName) {   
12.         this.firstName = firstName;   
13.     }   
14.   
15.     public void setLastName(String lastName) {   
16.         this.lastName = lastName;   
17.     }   
18.   
19.     public void setAge(int age) {   
20.         this.age = age;   
21.     }   
22. }  

@ThreadSafe
public class Person {
    private volatile String firstName;
    private volatile String lastName;
    private volatile int age;

    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public int getAge() { return age; }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

volatile 的高级模式
前面几节介绍的模式涵盖了大部分的基本用例，在这些模式中使用 volatile 非常有用并且简单。这一节将介绍一种更加高级的模式，在该模式中，volatile 将提供性能或可伸缩性优势。

volatile 应用的的高级模式非常脆弱。因此，必须对假设的条件仔细证明，并且这些模式被严格地封装了起来，因为即使非常小的更改也会损坏您的代码！同样，使用更高级的 volatile 用例的原因是它能够提升性能，确保在开始应用高级模式之前，真正确定需要实现这种性能获益。需要对这些模式进行权衡，放弃可读性或可维护性来换取可能的性能收益 —— 如果您不需要提升性能（或者不能够通过一个严格的测试程序证明您需要它），那么这很可能是一次糟糕的交易，因为您很可能会得不偿失，换来的东西要比放弃的东西价值更低。

模式 #5：开销较低的读－写锁策略
目前为止，您应该了解了 volatile 的功能还不足以实现计数器。因为 ++x 实际上是三种操作（读、添加、存储）的简单组合，如果多个线程凑巧试图同时对 volatile 计数器执行增量操作，那么它的更新值有可能会丢失。

然而，如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。清单 6 中显示的线程安全的计数器使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。

清单 6. 结合使用 volatile 和 synchronized 实现 “开销较低的读－写锁”

Java代码

1. @ThreadSafe  
2. public class CheesyCounter {   
3.     // Employs the cheap read-write lock trick   
4.     // All mutative operations MUST be done with the 'this' lock held   
5.     @GuardedBy("this") private volatile int value;   
6.   
7.     public int getValue() { return value; }   
8.   
9.     public synchronized int increment() {   
10.         return value++;   
11.     }   
12. }  

@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this") private volatile int value;

    public int getValue() { return value; }

    public synchronized int increment() {
        return value++;
    }
}

之所以将这种技术称之为 “开销较低的读－写锁” 是因为您使用了不同的同步机制进行读写操作。因为本例中的写操作违反了使用 volatile 的第一个条件，因此不能使用 volatile 安全地实现计数器 —— 您必须使用锁。然而，您可以在读操作中使用 volatile 确保当前值的可见性，因此可以使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作，因此当使用 volatile 保证读代码路径时，要比使用锁执行全部代码路径获得更高的共享度 —— 就像读－写操作一样。然而，要随时牢记这种模式的弱点：如果超越了该模式的最基本应用，结合这两个竞争的同步机制将变得非常困难。

结束语
与锁相比，Volatile 变量是一种非常简单但同时又非常脆弱的同步机制，它在某些情况下将提供优于锁的性能和伸缩性。如果严格遵循 volatile 的使用条件 —— 即变量真正独立于其他变量和自己以前的值 —— 在某些情况下可以使用 volatile 代替 synchronized 来简化代码。然而，使用 volatile 的代码往往比使用锁的代码更加容易出错。本文介绍的模式涵盖了可以使用 volatile 代替 synchronized 的最常见的一些用例。遵循这些模式（注意使用时不要超过各自的限制）可以帮助您安全地实现大多数用例，使用 volatile 变量获得更佳性能。

• 14:09
• 浏览 (48)
• 评论 (0)
• 分类: Java基础
• 发布在 java2d 圈子
• 收藏

2010 - 09 - 19

缩略显示

我奋斗了18年不是为了和你一起喝咖啡