深刻理解Java中的不可變對象

時間  2019-11-05
標籤 深刻 理解 java 不可變 對象 欄目 Java 简体版
原文   原文鏈接

深刻理解Java中的不可變對象

　　不可變對象想必大部分朋友都不陌生，你們在平時寫代碼的過程當中100%會使用到不可變對象，好比最多見的String對象、包裝器對象等，那麼到底爲什麼Java語言要這麼設計，真正意圖和考慮點是什麼？可能一些朋友沒有細想過這些問題，今天咱們就來聊聊跟不可變對象有關的話題。html

 　　如下是本文目錄大綱：java

　　一.什麼是不可變對象程序員

　　二.深刻理解不可變性編程

　　三.如何建立不可變對象安全

　　四.不可變對象真的"徹底不可改變"嗎？多線程

　　如有不正之處，但願諒解並歡迎批評指正。併發

　　請尊重做者勞動成果，轉載請標明原文連接：ide

　　https://www.cnblogs.com/dolphin0520/p/10693891.html函數

 

一.什麼是不可變對象

　　下面是《Effective Java》這本書對於不可變對象的定義：單元測試

不可變對象(Immutable Object)：對象一旦被建立後，對象全部的狀態及屬性在其生命週期內不會發生任何變化。

　　從不可變對象的定義來看，其實比較簡單，就是一個對象在建立後，不能對該對象進行任何更改。好比下面這段代碼：

public class ImmutableObject {
    private int value;
    
    public ImmutableObject(int value) {
        this.value = value;
    }
    
    public int getValue() {
        return this.value;
    }
}

　　因爲ImmutableObject不提供任何setter方法，而且成員變量value是基本數據類型，getter方法返回的是value的拷貝，因此一旦ImmutableObject實例被建立後，該實例的狀態沒法再進行更改，所以該類具有不可變性。

　　再好比咱們平時用的最多的String：

public class Test {

    public static void main(String[] args) {
        String str = "I love java";
        String str1 = str;

        System.out.println("after replace str:" + str.replace("java", "Java"));
        System.out.println("after replace str1:" + str1);
    }
}

　　輸出結果：

　　

　　從輸出結果能夠看出，在對str進行了字符串替換替換以後，str1指向的字符串對象仍然沒有發生變化。

二.深刻理解不可變性

　　咱們是否考慮過一個問題：假如Java中的String、包裝器類設計成可變的ok麼？若是String對象可變了，會帶來哪些問題？

　　咱們這一節主要來聊聊不可變對象存在的意義。

1）讓併發編程變得更簡單

　　說到併發編程，可能不少朋友都會以爲最苦惱的事情就是如何處理共享資源的互斥訪問，可能稍不留神，就會致使代碼上線後出現莫名其妙的問題，而且大部分併發問題都不是太容易進行定位和復現。因此即便是很是有經驗的程序員，在進行併發編程時，也會很是的當心，心裏如履薄冰。

　　大多數狀況下，對於資源互斥訪問的場景，都是採用加鎖的方式來實現對資源的串行訪問，來保證併發安全，如synchronize關鍵字，Lock鎖等。可是這種方案最大的一個難點在於：在進行加鎖和解鎖時須要很是地慎重。若是加鎖或者解鎖時機稍有一點誤差，就可能會引起重大問題，然而這個問題Java編譯器沒法發現，在進行單元測試、集成測試時可能也發現不了，甚至程序上線後也能正常運行，可是可能忽然在某一天，它就莫名其妙地出現了。

　　既然採用串行方式來訪問共享資源這麼容易出現問題，那麼有沒有其餘辦法來解決呢？

　　事實上，引發線程安全問題的根本緣由在於：多個線程須要同時訪問同一個共享資源。

　　假如沒有共享資源，那麼多線程安全問題就天然解決了，Java中提供的ThreadLocal機制就是採起的這種思想。

　　然而大多數時候，線程間是須要使用共享資源互通訊息的，若是共享資源在建立以後就徹底再也不變動，如同一個常量，而多個線程間併發讀取該共享資源是不會存在線上安全問題的，由於全部線程不管什麼時候讀取該共享資源，老是能獲取到一致的、完整的資源狀態。

　　不可變對象就是這樣一種在建立以後就再也不變動的對象，這種特性使得它們天生支持線程安全，讓併發編程變得更簡單。

　　咱們來看一個例子，這個例子來源於：http://ifeve.com/immutable-objects/

public class SynchronizedRGB {
    private int red;  // 顏色對應的紅色值
    private int green; // 顏色對應的綠色值
    private int blue;  // 顏色對應的藍色值
    private String name; // 顏色名稱

    private void check(int red, int green, int blue) {
        if (red < 0 || red > 255 || green < 0 || green > 255 
                || blue < 0 || blue > 255) {
            throw new IllegalArgumentException();
        }
    }

    public SynchronizedRGB(int red, int green, int blue, String name) {
        check(red, green, blue);
        this.red = red;
        this.green = green;
        this.blue = blue;
        this.name = name;
    }

    public void set(int red, int green, int blue, String name) {
        check(red, green, blue);
        synchronized (this) {
            this.red = red;
            this.green = green;
            this.blue = blue;
            this.name = name;
        }
    }

    public synchronized int getRGB() {
        return ((red << 16) | (green << 8) | blue);
    }

    public synchronized String getName() {
        return name;
    }
}

　　例如一個有個線程1執行了如下代碼：

SynchronizedRGB color =  new SynchronizedRGB(0, 0, 0, "Pitch Black");
int myColorInt = color.getRGB();      // Statement1
String myColorName = color.getName(); // Statement2

　　而後有另一個線程2在Statement 1以後、Statement 2以前調用了color.set方法：

color.set(0, 255, 0, "Green");

　　那麼在線程1中變量myColorInt的值和myColorName的值就會不匹配。爲了不出現這樣的結果，必需要像下面這樣把這兩條語句綁定到一塊執行：

synchronized (color) {
    int myColorInt = color.getRGB();
    String myColorName = color.getName();
}

　　假如SynchronizedRGB是不可變類，那麼就不會出現這個問題，好比將SynchronizedRGB改爲下面這種實現方式：

public class ImmutableRGB {
    private int red;
    private int green;
    private int blue;
    private String name;

    private void check(int red, int green, int blue) {
        if (red < 0 || red > 255 || green < 0 || green > 255
                || blue < 0 || blue > 255) {
            throw new IllegalArgumentException();
        }
    }

    public ImmutableRGB(int red, int green, int blue, String name) {
        check(red, green, blue);
        this.red = red;
        this.green = green;
        this.blue = blue;
        this.name = name;
    }

    public ImmutableRGB set(int red, int green, int blue, String name) {
        return new ImmutableRGB(red, green, blue, name);
    }

    public int getRGB() {
        return ((red << 16) | (green << 8) | blue);
    }

    public String getName() {
        return name;
    }
}

　　因爲set方法並無改變原來的對象，而是新建立了一個對象，因此不管線程1或者線程2怎麼調用set方法，都不會出現併發訪問致使的數據不一致的問題。

2）消除反作用

　　不少時候一些很嚴重的bug是因爲一個很小的反作用引發的，而且因爲反作用一般不容易被察覺，因此很難在編寫代碼以及代碼review過程當中發現，而且即便發現了也可能會花費很大的精力才能定位出來。

　　舉個簡單的例子：

class Person {
    private int age;   // 年齡
    private String identityCardID;  // 身份證號碼

    public int getAge() {
        return age;
    }

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

    public String getIdentityCardID() {
        return identityCardID;
    }

    public void setIdentityCardID(String identityCardID) {
        this.identityCardID = identityCardID;
    }
}


public class Test {

    public static void main(String[] args) {
        Person jack = new Person();
        jack.setAge(101);
        jack.setIdentityCardID("42118220090315234X");

        System.out.println(validAge(jack));
　　　　
　　　　// 後續使用可能沒有察覺到jack的age被修改了
　　　　// 爲後續埋下了不容易察覺的問題

    }

    public static boolean validAge(Person person) {
        if (person.getAge() >= 100) {
            person.setAge(100);  // 此處產生了反作用
            return false;
        }
        return true;
    }

}

　　validAge函數自己只是對age大小進行判斷，可是在這個函數裏面有一個反作用，就是對參數person指向的對象進行了修改，致使在外部的jack指向的對象也發生了變化。

　　若是Person對象是不可變的，在validAge函數中是沒法對參數person進行修改的，從而避免了validAge出現反作用，減小了出錯的機率。

3）減小容器使用過程出錯的機率

　　咱們在使用HashSet時，若是HashSet中元素對象的狀態可變，就會出現元素丟失的狀況，好比下面這個例子：

class Person {
    private int age;   // 年齡
    private String identityCardID;  // 身份證號碼

    public int getAge() {
        return age;
    }

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

    public String getIdentityCardID() {
        return identityCardID;
    }

    public void setIdentityCardID(String identityCardID) {
        this.identityCardID = identityCardID;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }

        if (!(obj instanceof  Person)) {
            return false;
        }
        Person personObj = (Person) obj;
        return this.age == personObj.getAge() && this.identityCardID.equals(personObj.getIdentityCardID());
    }

    @Override
    public int hashCode() {
        return age * 37 + identityCardID.hashCode();
    }
}


public class Test {

    public static void main(String[] args) {
        Person jack = new Person();
        jack.setAge(10);
        jack.setIdentityCardID("42118220090315234X");

        Set<Person> personSet = new HashSet<Person>();
        personSet.add(jack);

        jack.setAge(11);

        System.out.println(personSet.contains(jack));

    }
}

　輸出結果：

　　

　　因此在Java中，對於String、包裝器這些類，咱們常常會用他們來做爲HashMap的key，試想一下若是這些類是可變的，將會發生什麼？後果不可預知，這將會大大增長Java代碼編寫的難度。

三.如何建立不可變對象

　　一般來講，建立不可變類原則有如下幾條：

　　1）全部成員變量必須是private

　　2）最好同時用final修飾(非必須)

　　3）不提供可以修改原有對象狀態的方法

    • 最多見的方式是不提供setter方法

    • 若是提供修改方法，須要新建立一個對象，並在新建立的對象上進行修改

　　4）經過構造器初始化全部成員變量，引用類型的成員變量必須進行深拷貝(deep copy)

　　5）getter方法不能對外泄露this引用以及成員變量的引用

　　6）最好不容許類被繼承(非必須)

　　JDK中提供了一系列方法方便咱們建立不可變集合，如：

Collections.unmodifiableList(List<? extends T> list)

　　另外，在Google的Guava包中也提供了一系列方法來建立不可變集合，如：

ImmutableList.copyOf(list)

　　這2種方式雖然都能建立不可變list，可是二者是有區別的，JDK自帶提供的方式實際上建立出來的不是真正意義上的不可變集合，看unmodifiableList方法的實現就知道了：

　　能夠看出，實際上UnmodifiableList是將入參list的引用複製了一份，同時將全部的修改方法拋出UnsupportedOperationException。所以若是在外部修改了入參list，實際上會影響到UnmodifiableList，而Guava包提供的ImmutableList是真正意義上的不可變集合，它其實是對入參list進行了深拷貝。看下面這段測試代碼的結果便一目瞭然：

public class Test {

    public static void main(String[] args) {
        List<Integer> list = new ArrayList<Integer>();
        list.add(1);
        System.out.println(list);

        List unmodifiableList = Collections.unmodifiableList(list);
        ImmutableList immutableList = ImmutableList.copyOf(list);

        list.add(2);
        System.out.println(unmodifiableList);
        System.out.println(immutableList);

    }

}

　　輸出結果：

四.不可變對象真的"徹底不可改變"嗎？

　　不可變對象雖然具有不可變性，可是不是"徹底不可變"的，這裏打上引號是由於經過反射的手段是能夠改變不可變對象的狀態的。

　　你們看到這裏可能有疑惑了，爲何既然能改變，爲什麼還叫不可變對象？這裏面你們不要誤會不可變的本意，從不可變對象的意義分析能看出來對象的不可變性只是用來輔助幫助你們更簡單地去編寫代碼，減小程序編寫過程當中出錯的機率，這是不可變對象的初衷。若是真要靠經過反射來改變一個對象的狀態，此時編寫代碼的人也應該會意識到此類在設計的時候就不但願其狀態被更改，從而引發編寫代碼的人的注意。下面是經過反射方式改變不可變對象的例子：

public class Test {
    public static void main(String[] args) throws Exception {
        String s = "Hello World";
        System.out.println("s = " + s);

        Field valueFieldOfString = String.class.getDeclaredField("value");
        valueFieldOfString.setAccessible(true);

        char[] value = (char[]) valueFieldOfString.get(s);
        value[5] = '_';
        System.out.println("s = " + s);
    }

}

　　輸出結果：

 

參考文章：

http://ifeve.com/immutable-objects/

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程