volatile

volatile 的存在，解決了不同內(nèi)存間拷貝的同步問題，在每一次使用或者修改時(shí)候，都去原持有內(nèi)存中去拿最新的狀態(tài)

或者說可以這樣理解，volatile 的修飾讓線程放棄了使用各自內(nèi)存的做法轉(zhuǎn)而使用共享內(nèi)存，從而保證了可靠性，但是降低了效率

所以說我們只在需要不同線程訪問同一個(gè)值的時(shí)候才去打開這個(gè)限制

第一種情況

首先我們來寫一個(gè)測試代碼

public class Synchronized1Test {
    private boolean running = true;
    public void runTest() {
        new Thread() {
            @Override
            public void run() {
                while (running) {
                    System.out.println("線程開始執(zhí)行，，，，");
                }
            }
        }.start();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        stop();
    }
    private void stop() {
        running = false;
    }
}

代碼大致要表達(dá)的是，主線程在一秒之后要調(diào)用 stop 方法將 running = false，這樣，子線程的死循環(huán)就會(huì)被打破，這樣子線程停止執(zhí)行，主線程也執(zhí)行完畢，整個(gè)程序結(jié)束。

但是實(shí)際的執(zhí)行結(jié)果是，子線程的死循環(huán)并不會(huì)結(jié)束，會(huì)一直不停的執(zhí)行下去

這是因?yàn)榫€程直接做變量的值的修改并不是直接改的，而是先拷貝一份到自己線程的內(nèi)存區(qū)域，更改完之后再適時(shí)同步給原持有此值的線程，這樣做的目的是提高程序的運(yùn)行效率

而在這里，主線程持有此變量，子線程在執(zhí)行時(shí)候，將值拷貝了一份到自己的內(nèi)存中，然后子線程并沒有做值的修改，并不存在將值同步給主線程的過程，而此值的持有線程是主線程，主線程在更改完此值之后只會(huì)同步給自己，并不會(huì)同步給子線程，所以說子線程的值永遠(yuǎn)為最初拷貝走的值，永遠(yuǎn)為true，就永遠(yuǎn)不會(huì)停下來了。

有一個(gè)關(guān)鍵字 volatile 能解決這個(gè)問題

public class Synchronized1Test {
    private volatile boolean running = true;
	.....
}

volatile 的存在，解決了不同內(nèi)存間拷貝的同步問題，在每一次使用或者修改時(shí)候，都去原持有內(nèi)存中去拿最新的狀態(tài)，或者說可以這樣理解，volatile 的修飾讓線程放棄了使用各自內(nèi)存的做法轉(zhuǎn)而使用共享內(nèi)存，從而保證了可靠性，但是降低了效率，所以說我們只在需要不同線程訪問同一個(gè)值的時(shí)候才去打開這個(gè)限制

再次運(yùn)行，果然一秒結(jié)束

第二種情況

public class Synchronized2Test {
    private int x = 0;
    private void count() {
        x++;
    }
    public void runTest() {
        new Thread() {
            @Override
            public void run() {
                for (int i = 0; i < 1_000_000; i++) {
                    count();
                }
                System.out.println("x 在線程1的最終值" + x);
            }
        }.start();
        new Thread() {
            @Override
            public void run() {
                for (int i = 0; i < 1_000_000; i++) {
                    count();
                }
                System.out.println("x 在線程2的最終值" + x);
            }
        }.start();
    }
}

從代碼來看，兩個(gè)線程分別對同一個(gè)數(shù)進(jìn)行一百萬次從自增操作，無論誰最后執(zhí)行完成，理論上來講，總有一個(gè)線程打印出來的結(jié)果是兩百萬，但實(shí)際的運(yùn)行效果，無論執(zhí)行多少次都沒有兩百萬的結(jié)果出來。

都是因?yàn)樯衔恼f的，值的同步性問題，在各自內(nèi)存區(qū)域修改完后適時(shí)同步回去，導(dǎo)致的這個(gè)問題

然后我們加上 volatile 關(guān)鍵字

public class Synchronized2Test {
    private volatile int x = 0;
	.....
}

運(yùn)行，還是不行，為啥啊，都加上了怎么還是不行呢？

這里主要的原因是因?yàn)?x++; 這個(gè)操作

在 Java 中， x++; 是兩步操作，不是原子操作，是可拆的操作

他的運(yùn)算過程大致相當(dāng)于是

int temp = x + 1；
	x = temp；

這樣，在代碼分為兩行執(zhí)行的時(shí)候，搶線程的操作就發(fā)生了，就出現(xiàn)了值異常的情況

到目前為止，線程安全除了加 volatile 關(guān)鍵字外，還需要保證會(huì)互相影響的操作合成一個(gè)原子操作

這里解釋一下原子操作，簡單來說，把多個(gè)步驟看成一個(gè)整體，要么你別執(zhí)行我，要么就完全執(zhí)行，不要在執(zhí)行一半時(shí)候發(fā)生線程切換

這里引入我們保證一塊代碼塊執(zhí)行原子操作的關(guān)鍵字：synchronized

這時(shí)候我們改一下我們的代碼，給 count 方法增加 synchronized 關(guān)鍵字，并且可以將 volatile 關(guān)鍵字去除了

public class Synchronized2Test {
    private int x = 0;
    private synchronized void count() {
        x++;
    }
    .....
}

運(yùn)行，果然順利的打印出來了兩百萬，多次運(yùn)行也是這個(gè)結(jié)果

受保護(hù)的類型

到此，我們講一下官方提供的原子型的類型，這里拿之前出現(xiàn)過的 AtomicInteger 舉例

AtomicInteger 對標(biāo)的就是 int，他是對 int 的包裝，可以保證 int 具有同步性和原子性

這里的同步性可以理解為上文提到的被 volatile 修飾，原子性可以理解為被 synchronized 修飾

例：

// 可以理解為默認(rèn)值為 0 的 int
AtomicInteger count  = new AtomicInteger(0);
// 相當(dāng)于是 ++count
count.incrementAndGet();
// 相當(dāng)于是 count++
count.getAndIncrement();

代碼中的 count.incrementAndGet() 相當(dāng)于是 ++count

count.getAndIncrement() 相當(dāng)于是 count++

除此之外還有

不一一列舉

其中要說的就是 AtomicReference，他把傳入的范型，自動(dòng)幫我們做成了保護(hù)類型，使得在賦值和取值時(shí)候不出錯(cuò)

到此這篇關(guān)于Java線程安全之volatile詳解的文章就介紹到這了,更多相關(guān)Java的volatile內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論