麻豆狠色伊人亚洲综合网站 ,亚洲an天堂an在线观看,亚洲女人被黑人巨大进入

�~�写多线�E�Java应用中的死锁问题

RoyPayne — Mon, 10 Dec 2012 02:54:00 GMT

死锁是一个经典的多线�E�问题，因�ؓ不同的线�E�都在等待那些根本不可能被释攄��锁，

从而导致所有的工作都无法完成。假设有两个�U�程�Q�分别代表两个饥饿的人，他们必须�׃�n刀叉�ƈ轮流吃饭�?/div>

他们都需要获得两个锁�Q�共享刀和共享叉的锁。假如线�E?"A" 获得了刀�Q�而线�E?"B" 获得了叉�?/div>

�U�程 A ��׃��q�入��d��状态来�{�待获得叉，而线�E?B 则阻塞来�{�待 A 所拥有的刀�?br />

让所有的�U�程按照同样的顺序获得一�l�锁。这�U�方法消除了 X �?Y 的拥有者分别等待对方的资源的问题�?/div>

　　��多个锁�l�成一�l��ƈ攑ֈ�同一个锁下。前面死锁的例子中，可以创徏一个银器对象的锁。于是在获得刀或叉之前都必��获得这个银器的锁�?/div>

　　��那些不会阻塞的可获得资源用变量标志出来。当某个�U�程获得银器对象的锁�Ӟ��可以通过��查变量来判断是否整个银器集合中的对象锁都可获得。如果是�Q�它��可以获得相关的锁，否则�Q�就要释放掉银器�q�个锁�ƈ�E�后再尝试�?/div>

　　最重要的是�Q�在�~�写代码前认真仔�l�地设计整个�pȝ��。多�U�程是困隄��Q�在开始编�E�之前详�l�设计系�l�能够帮助你避免难以发现死锁的问题�?/div>

RoyPayne 2012-12-10 10:54 发表评论

java.util.ConcurrentModificationException

RoyPayne — Fri, 06 Jan 2012 09:14:00 GMT

工作中碰��C��ConcurrentModificationException。代码如下：
List list = ...;
for(Iterator iter = list.iterator(); iter.hasNext();) {
    Object obj = iter.next();
    ...
    if(***) {
        list.remove(obj);
    }
}
在执行了remove�Ҏ��之后�Q�再��L��行��@环，iter.next()的时候，报java.util.ConcurrentModificationException(当然�Q�如果remove的是最后一条，��׃��会再��L��行next()操作�?

下面来看一下源�?/span>
public interface Iterator {
    boolean hasNext();
    E next();
    void remove();
}

public interface Collection extends Iterable {
    ...
    Iterator iterator();
    boolean add(E o);
    boolean remove(Object o);
    ...
}
�q�里有两个remove�Ҏ��

接下来来看看AbstractList
public abstract class AbstractList extends AbstractCollection implements List {
//AbstractCollection和List都��承了Collection
    protected transient int modCount = 0;
    private class Itr implements Iterator { //内部�c�Itr
        int cursor = 0;
        int lastRet = -1;
        int expectedModCount = modCount;

        public boolean hasNext() {
            return cursor != size();
        }

        public E next() {
            checkForComodification();  //特别注意�q�个�Ҏ��
            try {
                E next = get(cursor);
                lastRet = cursor++;
                return next;
            } catch(IndexOutOfBoundsException e) {
                checkForComodification();
                throw new NoSuchElementException();
            }
        }

        public void remove() {
            if (lastRet == -1)
                throw new IllegalStateException();
            checkForComodification();

            try {
                AbstractList.this.remove(lastRet);  //执行remove对象的操�?br style="box-sizing: border-box; " />                if (lastRet < cursor)
                    cursor--;
                lastRet = -1;
                expectedModCount = modCount;  //重新讄��了expectedModCount的��|��避免了ConcurrentModificationException的��?br style="box-sizing: border-box; " />            } catch(IndexOutOfBoundsException e) {
                throw new ConcurrentModificationException();
            }
        }

        final void checkForComodification() {
            if (modCount != expectedModCount)  //当expectedModCount和modCount不相�{�时�Q�就抛出ConcurrentModificationException
                throw new ConcurrentModificationException();
        }
    }
}

remove(Object o)在ArrayList中实现如下：
public boolean remove(Object o) {
    if (o == null) {
            for (int index = 0; index < size; index++)
        if (elementData[index] == null) {
            fastRemove(index);
            return true;
        }
    } else {
        for (int index = 0; index < size; index++)
            if (o.equals(elementData[index])) {
                fastRemove(index);
                return true;
            }
    }
    return false;
}
private void fastRemove(int index) {
    modCount++;  //只增加了modCount
    ....
}

所以，产生ConcurrentModificationException的原因就是：
执行remove(Object o)�Ҏ��之后�Q�modCount和expectedModCount不相�{�了。然后当代码执行到next()�Ҏ��Ӟ��判断了checkForComodification()�Q�发��C��个数��g��{�，��抛��Z��该Exception�?br style="box-sizing: border-box; " />要避免这个Exception�Q�就应该使用remove()�Ҏ��?/strong>
�q�里我们��׃��看add(Object o)�Ҏ��了，也是同样的原因，但没有对应的add()�Ҏ��。一般嘛�Q�就另徏一个List�?/span>

下面是网上的其他解释�Q�更能从本质上解释原因：
Iterator 是工作在一个独立的�U�程中，�q�且拥有一�?mutex 锁�?Iterator 被创��Z��后会建立一个指向原来对象的单链索引表，当原来的对象数量发生变化�Ӟ��q�个索引表的内容不会同步改变�Q�所以当索引指针往后移动的时候就找不到要�q�代的对象，所以按�?fail-fast 原则 Iterator 会马上抛�?java.util.ConcurrentModificationException 异常�?/span>
所�?Iterator 在工作的时候是不允许被�q�代的对象被改变的。但你可以��?Iterator 本��n的方�?remove() 来删除对象， Iterator.remove() �Ҏ��会在删除当前�q�代对象的同时维护烦引的一致性�?/span>

RoyPayne 2012-01-06 17:14 发表评论

�U�程----BlockingQueue (�?

RoyPayne — Fri, 06 Jan 2012 08:32:00 GMT

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

/**
    本例介绍一个特�D�的队列:BlockingQueue,如果BlockQueue是空�?从BlockingQueue取东西的操作��会被阻断进入等待状�?直到BlockingQueue�q�了东西才会被唤�?同样,如果BlockingQueue是满�?��M��试图往里存东西的操作也会被��L��q�入�{�待状�?直到BlockingQueue里有�I�间才会被唤醒��l�操�?
    本例再次实现11.4�U�程----条�gCondition中介�l�的��子�E�序,不过�q�个��子中最多能攄��Ҏ��C��?,可以随意指定.当篮子满�?生��者进入等待状�?当篮子空�?消费者等�?
*/
/**
    使用BlockingQueue的关键技术点如下:
    1.BlockingQueue定义的常用方法如�?
        1)add(anObject):把anObject加到BlockingQueue�?卛_��果BlockingQueue可以容纳,则返回true,否则招聘异常
        2)offer(anObject):表示如果可能的话,��anObject加到BlockingQueue�?卛_��果BlockingQueue可以容纳,则返回true,否则�q�回false.
        3)put(anObject):把anObject加到BlockingQueue�?如果BlockQueue没有�I�间,则调用此�Ҏ��的线�E�被��L��直到BlockingQueue里面有空间再�l�箋.
        4)poll(time):取走BlockingQueue里排在首位的对象,若不能立卛_��?则可以等time参数规定的时�?取不到时�q�回null
        5)take():取走BlockingQueue里排在首位的对象,若BlockingQueue为空,��L��q�入�{�待状态直到Blocking有新的对象被加入为止
    2.BlockingQueue有四个具体的实现�c?�Ҏ��不同需�?选择不同的实现类
        1)ArrayBlockingQueue:规定大小的BlockingQueue,其构造函数必��d��一个int参数来指明其大小.其所含的对象是以FIFO(先入先出)��序排序�?
        2)LinkedBlockingQueue:大小不定的BlockingQueue,若其构造函数带一个规定大��的参数,生成的BlockingQueue有大��限�?若不带大��参�?所生成的BlockingQueue的大��由Integer.MAX_VALUE来决�?其所含的对象是以FIFO(先入先出)��序排序�?br />        3)PriorityBlockingQueue:�c�M��于LinkedBlockQueue,但其所含对象的排序不是FIFO,而是依据对象的自然排序顺序或者是构造函数的Comparator军_��的顺�?
        4)SynchronousQueue:�Ҏ��的BlockingQueue,对其的操作必��L��攑֒�取交替完成的.
    3.LinkedBlockingQueue和ArrayBlockingQueue比较��h��,它们背后所用的数据�l�构不一�?��D��LinkedBlockingQueue的数据吞吐量要大于ArrayBlockingQueue,但在�U�程数量很大时其性能的可预见性低于ArrayBlockingQueue.
*/
public class BlockingQueueTest {
       /**定义装苹果的��子*/
       public static class Basket{
              //��子,能够容纳3个苹�?/span>
              BlockingQueue basket = new ArrayBlockingQueue(3);
              //生��Ҏ��,攑օ��子
              public void produce() throws InterruptedException{
                     //put�Ҏ��攑օ�一个苹�?若basket满了,�{�到basket有位�|?/span>
                     basket.put("An apple");
              }
              //消费�Ҏ��,从篮子中取走
              public String consume() throws InterruptedException{
                     //take�Ҏ��取出一个苹�?若basket为空,�{�到basket有苹果�ؓ�?/span>
                     return basket.take();
              }
       }
       //��试�Ҏ��
       public static void testBasket(){
              final Basket basket = new Basket();//建立一个装�Ҏ��的篮�?br />              //定义�Ҏ��生��?/span>
              class Producer implements Runnable{
                     public void run(){
                            try{
                                   while(true){
                                          //生��Ҏ��
                                          System.out.println("生��者准备生产苹�? " + System.currentTimeMillis());
                                          basket.produce();
                                          System.out.println("生��者生产苹果完�? " + System.currentTimeMillis());
                                          //休眠300ms
                                          Thread.sleep(300);
                                   }
                            }catch(InterruptedException ex){
                            }
                     }
              }
              //定义�Ҏ��消费�?/span>
              class Consumer implements Runnable{
                     public void run(){
                            try{
                                   while(true){
                                          //消费�Ҏ��
                                          System.out.println("消费者准备消费苹�? " + System.currentTimeMillis());
                                          basket.consume();
                                          System.out.println("消费者消费苹果完�? " + System.currentTimeMillis());
                                          //休眠1000ms
                                          Thread.sleep(1000);
                                   }
                            }catch(InterruptedException ex){
                            }
                     }
              }
              ExecutorService service = Executors.newCachedThreadPool();
              Producer producer = new Producer();
              Consumer consumer = new Consumer();
              service.submit(producer);
              service.submit(consumer);
              //�E�序�q�行5s�?所有�Q务停�?/span>
              try{
                     Thread.sleep(5000);
              }catch(InterruptedException ex){
              }
              service.shutdownNow();
       }
       public static void main(String[] args){
              BlockingQueueTest.testBasket();
       }
}

RoyPayne 2012-01-06 16:32 发表评论

如何在java中正��用volatile

RoyPayne — Fri, 06 Jan 2012 02:44:00 GMT

　 Java? 语言包含两种内在的同步机�Ӟ��同步块（或方法）�?volatile 变量。这两种机制的提出都是�ؓ了实��C��码线�E�的安全性。其�?Volatile 变量的同步性较差（但有时它更简单�ƈ且开销更低�Q�，而且其��用也更容易出错。在�q�期�?nbsp;Java 理论与实�?/em>中，Brian Goetz ��介�l�几�U�正��?volatile 变量的模式，�q��对其适用性限制提��Z��些徏议�?/span>
　　Java 语言中的 volatile 变量可以被看作是一�U?“�E�度较轻�?synchronized”�Q�与 synchronized 块相比，volatile 变量所需的编码较��，�q�且�q�行时开销也较��，但是它所能实现的功能也仅�?synchronized 的一部分。本文介�l�了几种有效使用 volatile 变量的模式，�q�强调了几种不适合使用 volatile 变量的情形�?/span>
　　锁提供了两种主要�Ҏ��：互斥�Q�mutual exclusion�Q?/em>�?/span>可见性（visibility�Q?/em>。互斥即一�ơ只允许一个线�E�持有某个特定的锁，因此可��用该�Ҏ��实现对�׃�n数据的协调访问协议，�q�样�Q�一�ơ就只有一个线�E�能够��用该�׃�n数据。可见性要更加复杂一些，它必��ȝ��保释��N��之前对共享数据做出的更改对于随后获得该锁的另一个线�E�是可见�?—— 如果没有同步机制提供的这�U�可见性保证，�U�程看到的共享变量可能是修改前的值或不一致的��|��q�将引发许多严重问题�?/span>
Volatile 变量
　　Volatile 变量��h�� synchronized 的可见性特性，但是不具备原子特性。这��是说线�E�能够自动发�?volatile 变量的最新倹{��Volatile 变量可用于提供线�E�安全，但是只能应用于非常有限的一�l�用例：多个变量之间或者某个变量的当前��g��修改后��g��间没有约束。因此，单独使用 volatile �q�不��以实现计数器、互斥锁或�Q何具有与多个变量相关的不变式�Q�Invariants�Q�的�c�（例如 “start <=end”�Q��?/span>
　　��Z��易性或可�׾~�性的考虑�Q�您可能們֐�于��?volatile 变量而不是锁。当使用 volatile 变量而非锁时�Q�某些习惯用法（idiom�Q�更加易于编码和阅读。此外，volatile 变量不会像锁那样造成�U�程��d��Q�因此也很少造成可�׾~�性问题。在某些情况下，如果��L��作远�q�大于写操作�Q�volatile 变量�q�可以提供优于锁的性能优势�?/span>
正确使用 volatile 变量的条�?/h3>　　您只能在有限的一些情形下使用 volatile 变量替代锁。要�?volatile 变量提供理想的线�E�安全，必须同时满��下面两个条�g�Q?/span>
　　● 对变量的写操作不依赖于当前倹{�?/span>
　　● 该变量没有包含在��h��其他变量的不变式中�?/span>
　　实际上，�q�些条�g表明�Q�可以被写入 volatile 变量的这些有效值独立于��M��E�序的状态，包括变量的当前状态�?/span>
　　�W�一个条件的限制�?volatile 变量不能用作�U�程安全计数器。虽然增量操作（x++�Q�看上去�c�M��一个单独操作，实际上它是一个由��d��Q�修改－写入操作序列�l�成的组合操作，必须以原子方式执行，�?volatile 不能提供必须的原子特性。实现正��的操作需要�� x 的值在操作期间保持不变�Q��?volatile 变量无法实现�q�点。（然而，如果��D��整�ؓ只从单个�U�程写入�Q�那么可以忽略第一个条件。）
　　大多数编�E�情形都会与�q�两个条件的其中之一冲突�Q��?volatile 变量不能�?synchronized 那样普遍适用于实现线�E�安全。清�?1 昄��了一个非�U�程安全的数��D��围类。它包含了一个不变式 —— 下界��L��于或等于上界�?br />
清单 1. 非线�E�安全的数��D��围类
@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;
}
}

�q�种方式限制了范围的状态变量，因此��?lower �?upper 字段定义�?volatile �c�d��不能够充分实现类的线�E�安全；从而仍焉��要��用同步。否则，如果凑��y两个�U�程在同一旉��使用不一致的值执�?setLower �?setUpper 的话�Q�则会��范围处于不一致的状态。例如，如果初始状态是 (0, 5)�Q�同一旉��内，�U�程 A 调用 setLower(4) �q�且�U�程 B 调用 setUpper(3)�Q�显然这两个操作交叉存入的值是不符合条件的�Q�那么两个线�E�都会通过用于保护不变式的��查，使得最后的范围值是 (4, 3) —— 一个无效倹{��至于针对范围的其他操作�Q�我们需要�� setLower() �?setUpper() 操作原子�?—— 而将字段定义�?volatile �c�d��是无法实现这一目的的�?/span>
性能考虑
　　使用 volatile 变量的主要原因是其简易性：在某些情形下�Q��?volatile 变量要比使用相应的锁��单得多。��?volatile 变量�ơ要原因是其性能�Q�某些情况下�Q�volatile 变量同步机制的性能要优于锁�?/span>
　　很难做出准确、全面的评�h�Q�例�?“X ��L��?Y �?#8221;�Q�尤其是�?JVM 内在的操作而言。（例如�Q�某些情况下 VM 也许能够完全删除锁机�Ӟ��q��得我们难以抽象地比较 volatile�?synchronized 的开销。）��是��_��在目前大多数的处理器架构上，volatile ��L��作开销非常�?—— 几乎和非 volatile ��L��作一栗��?volatile 写操作的开销要比�?volatile 写操作多很多�Q�因��保证可见性需要实现内存界定（Memory Fence�Q�，即便如此�Q�volatile 的��d��销仍然要比锁获取低�?/span>
　　volatile 操作不会像锁一样造成��d��Q�因此，在能够安全��?volatile 的情况下�Q�volatile 可以提供一些优于锁的可伸羃�Ҏ��。如果读操作的次数要�q�远��过写操作，与锁相比�Q�volatile 变量通常能够减少同步的性能开销�?/span>
正确使用 volatile 的模�?/h3>　　很多�q�发性专家事实上往往引导用户�q�离 volatile 变量�Q�因��Z��用它们要比��用锁更加�Ҏ��出错。然而，如果谨慎地遵循一些良好定义的模式�Q�就能够在很多场合内安全��C��?volatile 变量。要始终牢记使用 volatile 的限�?—— 只有在状态真正独立于�E�序内其他内�Ҏ��才能使用 volatile —— �q�条规则能够避免��这些模式扩展到不安全的用例�?/span>
　　模式 #1�Q�状态标�?/strong> 也许实现 volatile 变量的规范��用仅仅是使用一个布��状态标志，用于指示发生了一个重要的一�ơ性事�Ӟ��例如完成初始化或��h��停机�?/span>
　　很多应用�E�序包含了一�U�控制结构，形式�?“在还没有准备好停止程序时再执行一些工�?#8221;�Q�如清单 2 所�C�：
　　清单 2. ��?volatile 变量作�ؓ状态标志��?/strong>

volatile boolean shutdownRequested;

public void shutdown() { shutdownRequested = true; }
public void doWork() {
while (!shutdownRequested) {
// do stuff
}
}
很可能会从��@环外部调�?shutdown() �Ҏ�� —— 卛_��另一个线�E�中 —— 因此�Q�需要执行某�U�同步来��保正确实现 shutdownRequested 变量的可见性。（可能会从 JMX 侦听�E�序、GUI 事�g�U�程中的操作侦听�E�序、通过 RMI 、通过一�?Web 服务�{�调用）。然而，使用 synchronized 块编写��@环要比��用清�?2 所�C�的 volatile 状态标志编写麻烦很多。由�?volatile ��化了�~�码�Q��ƈ且状态标志�ƈ不依赖于�E�序内�Q何其他状态，因此此处非常适合使用 volatile�?/span>
　　�q�种�c�d��的状态标记的一个公��q��性是�Q�通常只有一�U�状态�{换；shutdownRequested 标志�?false 转换�?true�Q�然后程序停止。这�U�模式可以扩展到来回转换的状态标志，但是只有在�{换周期不被察觉的情况下才能扩展（�?false �?true�Q�再转换�?false�Q�。此外，�q�需要某些原子状态�{换机�Ӟ��例如原子变量�?/span>
　　模式 #2�Q�一�ơ性安全发布（one-time safe publication�Q?/strong>
　　�~�Z��同步会导致无法实现可见性，�q��得确定何时写入对象引用而不是原语值变得更加困难。在�~�Z��同步的情况下�Q�可能会遇到某个对象引用的更新��|��由另一个线�E�写入）和该对象状态的旧值同时存在。（�q�就是造成著名的双重检查锁定（double-checked-locking�Q�问题的�Ҏ��Q�其中对象引用在没有同步的情况下�q�行��L��作，产生的问题是您可能会看到一个更新的引用�Q�但是仍然会通过该引用看��C��完全构造的对象�Q��?/span>
　　实现安全发布对象的一�U�技术就是将对象引用定义�?volatile �c�d��。清�?3 展示了一个示例，其中后台�U�程在启动阶�D�从数据库加载一些数据。其他代码在能够利用�q�些数据�Ӟ��在��用之前将��查这些数据是否曾�l�发布过�?/span>
　　清单 3. ��?volatile 变量用于一�ơ性安全发�?/strong>

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 �c�d��Q�doWork() 中的代码在解除对 theFlooble 的引用时�Q�将会得��C��个不完全构造的 Flooble�?/span>
　　该模式的一个必要条件是�Q�被发布的对象必��L��U�程安全的，或者是有效的不可变对象�Q�有效不可变意味着对象的状态在发布之后永远不会被修改）。volatile �c�d��的引用可以确保对象的发布形式的可见性，但是如果对象的状态在发布后将发生更改�Q�那么就需要额外的同步�?/span>
　　模式 #3�Q�独立观察（independent observation�Q?/strong>
　　安全使用 volatile 的另一�U�简单模式是�Q�定�?“发布” 观察�l�果供程序内部��用。例如，假设有一�U�环境传感器能够感觉环境温度。一个后台线�E�可能会每隔几秒��d��一�ơ该传感器，�q�更新包含当前文档的 volatile 变量。然后，其他�U�程可以��d��q�个变量�Q�从而随时能够看到最新的温度倹{�?/span>
　　使用该模式的另一�U�应用程序就是收集程序的�l�计信息。清�?4 展示了��n份验证机制如何记忆最�q�一�ơ登录的用户的名字。将反复使用 lastUser 引用来发布��|��以供�E�序的其他部分��用�?/span>
　　清单 4. ��?volatile 变量用于多个独立观察�l�果的发�?/span>
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;
}
}

该模式是前面模式的扩展；��某个值发布以在程序内的其他地方��用，但是与一�ơ性事件的发布不同�Q�这是一�p�d��独立事�g。这个模式要求被发布的值是有效不可变的 —— 卛_��的状态在发布后不会更攏V��用该值的代码需要清楚该值可能随时发生变化�?/span>
　　模式 #4�Q?#8220;volatile bean” 模式
　　volatile bean 模式适用于将 JavaBeans 作�ؓ“荣誉�l�构”使用的框架。在 volatile bean 模式中，JavaBean 被用作一�l�具�?getter �?�?setter �Ҏ�� 的独立属性的容器。volatile bean 模式的基本原理是�Q�很多框架�ؓ易变数据的持有者（例如 HttpSession�Q�提供了容器�Q�但是放入这些容器中的对象必��L��U�程安全的�?/span>
　　�?volatile bean 模式中，JavaBean 的所有数据成员都�?volatile �c�d��的，�q�且 getter �?setter �Ҏ��必须非常普�?—— 除了获取或设�|�相应的属性外�Q�不能包含�Q何逻辑。此外，对于对象引用的数据成员，引用的对象必��L��有效不可变的。（�q�将��止��h��数组值的属性，因�ؓ当数�l�引用被声明�?volatile �Ӟ��只有引用而不是数�l�本�w�具�?volatile 语义�Q�。对于�Q�?volatile 变量�Q�不变式或约束都不能包含 JavaBean 属性。清�?5 中的�C�Z��展示了遵�?volatile bean 模式�?JavaBean�Q?/span>
　　清单 5. 遵守 volatile bean 模式�?Person 对象

@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 的高�U�模�?/strong>
　　前面几节介绍的模式涵盖了大部分的基本用例�Q�在�q�些模式中��?volatile 非常有用�q�且��单。这一节将介绍一�U�更加高�U�的模式�Q�在该模式中�Q�volatile ��提供性能或可伸羃性优�ѝ�?/span>
　　volatile 应用的的高��模式非常脆弱。因此，必须对假讄��条�g仔细证明�Q��ƈ且这些模式被严格地封装了��h��Q�因为即佉K��常小的更改也会损坏您的代码！同样�Q��用更高��?volatile 用例的原因是它能够提升性能�Q�确保在开始应用高�U�模式之前，真正��定需要实现这�U�性能��L��。需要对�q�些模式�q�行权衡�Q�放弃可��L��或可维护性来换取可能的性能收益 —— 如果您不需要提升性能�Q�或者不能够通过一个严格的��试�E�序证明您需要它�Q�，那么�q�很可能是一�ơ糟�p�的交易�Q�因为您很可能会得不偿失�Q�换来的东西要比攑ּ�的东西�h值更低�?/span>
　　模式 #5�Q�开销较低的读�Q�写锁策�?/strong>
　　目前为止�Q�您应该了解�?volatile 的功能还不��以实现计数器。因�?++x 实际上是三种操作�Q�读、添加、存储）的简单组合，如果多个�U�程凑��y试图同时�?volatile 计数器执行增量操作，那么它的更新值有可能会丢失�?/span>
　　然而，如果��L��作远�q�超�q�写操作�Q�您可以�l�合使用内部锁和 volatile 变量来减��公�׃��码�\径的开销。清�?6 中显�C�的�U�程安全的计数器使用 synchronized ��保增量操作是原子的�Q��ƈ使用 volatile 保证当前�l�果的可见性。如果更��C��频繁的话�Q�该�Ҏ��可实现更好的性能�Q�因��路径的开销仅仅涉及 volatile ��L��作，�q�通常要优于一个无竞争的锁获取的开销�?/span>
　　清单 6. �l�合使用 volatile �?synchronized 实现 “开销较低的读�Q�写�?#8221;
@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 volatileint value;
public int getValue() { return value; }
public synchronizedint increment() {
return value++;
}
}

之所以将�q�种技术称之�ؓ “开销较低的读�Q�写�?#8221; 是因为您使用了不同的同步机制�q�行��d��操作。因为本例中的写操作�q�反了��?volatile 的第一个条�Ӟ��因此不能使用 volatile 安全地实现计数器 —— 您必��M��用锁。然而，您可以在��L��作中使用 volatile ��保当前值的可见�?/em>�Q�因此可以��用锁�q�行所有变化的操作�Q��?volatile �q�行只读操作。其中，锁一�ơ只允许一个线�E�访问��|��volatile 允许多个�U�程执行��L��作，因此当��?volatile 保证��M��码�\径时�Q�要比��用锁执行全部代码路径获得更高的共享度 —— ��像读－写操作一栗��然而，要随时牢记这�U�模式的��q��Q�如果超��了该模式的最基本应用�Q�结合这两个竞争的同步机制将变得非常困难�?/span>
　　�l�束�?/strong>
　　与锁相比�Q�Volatile 变量是一�U�非常简单但同时又非常脆��q��同步机制�Q�它在某些情况下��提供优于锁的性能和�׾~�性。如果严格遵�?volatile 的��用条�?—— 卛_��量真正独立于其他变量和自�׃��前的�?—— 在某些情况下可以使用 volatile 代替 synchronized 来简化代码。然而，使用 volatile 的代码往往比��用锁的代码更加容易出错。本文介�l�的模式�늛�了可以��?volatile 代替 synchronized 的最常见的一些用例。遵循这些模式（注意使用时不要超�q�各自的限制�Q�可以帮助您安全地实现大多数用例�Q��?volatile 变量获得更佳性能�?/span>

RoyPayne 2012-01-06 10:44 发表评论

RoyPayne — Thu, 05 Jan 2012 06:32:00 GMT

两者的区别有：
1、最主要是sleep�Ҏ��没有释放锁，而wait�Ҏ��释放了锁�Q��得其�?a target="_blank" style="color: #005599; text-decoration: none; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #005599; ">�U�程可以使用同步控制块或者方法�?2、这两个�Ҏ��来自不同的类分别是Thread和Object

3、wait�Q�notify和notifyAll只能在同步控制方法或者同步控制块里面使用�Q�而sleep可以�?br /> ��M��地方使用
synchronized(x){
x.notify()
//或者wait()
}
4、sleep必须捕获异常�Q�而wait�Q�notify和notifyAll不需要捕获异�?/pre>

RoyPayne 2012-01-05 14:32 发表评论

Lock和Synchronized

RoyPayne — Wed, 28 Dec 2011 09:22:00 GMT
java锁机制有两种实现方式�Q�jdk1.4 通过synchronized的方式实玎ͼ�jdk1.5加入java.util.concurrent.locks包下的各�U�lock

1.代码层的区别�?br />synchronized �c�M��面向对象修饰 �c�，�Ҏ��Q�对象�?br />lock不作��Z��饎ͼ��c�M��面向�q�程�Q�在�Ҏ��中需要锁的时候lock�Q�在�l�束的时候unlock。（一般在finally块里�Q?br />
2.性能
�q�发高，lock有优�ѝ��低�q�发 synchronized 有优�ѝ�?br />
3.实现机制

synchronized 对象加锁

RoyPayne 2011-12-28 17:22 发表评论

java 里面volatile什么意思啊

RoyPayne — Wed, 28 Dec 2011 05:58:00 GMT

Volatile修饰的成员变量在每次被线�E�访问时�Q�都��从共享内存中重读该成员变量的倹{��而且�Q�当成员变量发生变化�Ӟ��U�程��变化值回写到�׃�n内存。这样在��M��时刻�Q�两

个不同的�U�程��L��看到某个成员变量的同一个倹{�? Java语言规范中指出：��Z��获得最佳速度�Q�允许线�E�保存共享成员变量的�U�有拯��Q�而且只当�U�程�q�入或者离开同步代码块时才与

�׃�n成员变量的原始值对比�? �q�样当多个线�E�同时与某个对象交互�Ӟ��必��要注意到要让线�E�及时的得到�׃�n成员变量的变化�? 而volatile关键字就是提�C�VM�Q�对于这个成员变�?/span>

不能保存它的�U�有拯��Q�而应直接与共享成员变量交互�? 使用��Q�在两个或者更多的�U�程讉K��的成员变量上使用volatile。当要访问的变量已在synchronized代码块中�Q�或者�ؓ帔R��

�Ӟ��不必使用�? �׃��使用volatile屏蔽掉了VM中必要的代码优化�Q�所以在效率上比较低�Q�因此一定在必要时才使用此关键字�? ��p��C中的一�?��止�~�译器进行优化~~~~

RoyPayne 2011-12-28 13:58 发表评论

麻豆狠色伊人亚洲综合网站 ,亚洲an天堂an在线观看,亚洲女人被黑人巨大进入

�~�写多线�E�Java应用中的死锁问题

java.util.ConcurrentModificationException

�U�程----BlockingQueue (�?

如何在java中正�����用volatile

Volatile 变量

性能考虑

Lock和Synchronized

java 里面volatile什么意思啊

如何在java中正��用volatile