欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

詳解Java中的不可變對(duì)象

 更新時(shí)間:2020年06月10日 10:01:54   作者:Matrix海子  
這篇文章主要介紹了Java中的不可變對(duì)象的相關(guān)知識(shí),文中代碼非常詳細(xì),幫助大家更好的理解和學(xué)習(xí),感興趣的朋友可以參考下

不可變對(duì)象想必大部分朋友都不陌生,大家在平時(shí)寫(xiě)代碼的過(guò)程中100%會(huì)使用到不可變對(duì)象,比如最常見(jiàn)的String對(duì)象、包裝器對(duì)象等,那么到底為何Java語(yǔ)言要這么設(shè)計(jì),真正意圖和考慮點(diǎn)是什么?可能一些朋友沒(méi)有細(xì)想過(guò)這些問(wèn)題,今天我們就來(lái)聊聊跟不可變對(duì)象有關(guān)的話(huà)題。

一.什么是不可變對(duì)象 

下面是《Effective Java》這本書(shū)對(duì)于不可變對(duì)象的定義:

        不可變對(duì)象(Immutable Object):對(duì)象一旦被創(chuàng)建后,對(duì)象所有的狀態(tài)及屬性在其生命周期內(nèi)不會(huì)發(fā)生任何變化。

  從不可變對(duì)象的定義來(lái)看,其實(shí)比較簡(jiǎn)單,就是一個(gè)對(duì)象在創(chuàng)建后,不能對(duì)該對(duì)象進(jìn)行任何更改。比如下面這段代碼:

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

       由于ImmutableObject不提供任何setter方法,并且成員變量value是基本數(shù)據(jù)類(lèi)型,getter方法返回的是value的拷貝,所以一旦ImmutableObject實(shí)例被創(chuàng)建后,該實(shí)例的狀態(tài)無(wú)法再進(jìn)行更改,因此該類(lèi)具備不可變性。

  再比如我們平時(shí)用的最多的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);
 }
}

輸出結(jié)果:

 從輸出結(jié)果可以看出,在對(duì)str進(jìn)行了字符串替換替換之后,str1指向的字符串對(duì)象仍然沒(méi)有發(fā)生變化。

二.深入理解不可變性

  我們是否考慮過(guò)一個(gè)問(wèn)題:假如Java中的String、包裝器類(lèi)設(shè)計(jì)成可變的ok么?如果String對(duì)象可變了,會(huì)帶來(lái)哪些問(wèn)題?

  我們這一節(jié)主要來(lái)聊聊不可變對(duì)象存在的意義。

1)讓并發(fā)編程變得更簡(jiǎn)單

  說(shuō)到并發(fā)編程,可能很多朋友都會(huì)覺(jué)得最苦惱的事情就是如何處理共享資源的互斥訪(fǎng)問(wèn),可能稍不留神,就會(huì)導(dǎo)致代碼上線(xiàn)后出現(xiàn)莫名其妙的問(wèn)題,并且大部分并發(fā)問(wèn)題都不是太容易進(jìn)行定位和復(fù)現(xiàn)。所以即使是非常有經(jīng)驗(yàn)的程序員,在進(jìn)行并發(fā)編程時(shí),也會(huì)非常的小心,內(nèi)心如履薄冰。

  大多數(shù)情況下,對(duì)于資源互斥訪(fǎng)問(wèn)的場(chǎng)景,都是采用加鎖的方式來(lái)實(shí)現(xiàn)對(duì)資源的串行訪(fǎng)問(wèn),來(lái)保證并發(fā)安全,如synchronize關(guān)鍵字,Lock鎖等。但是這種方案最大的一個(gè)難點(diǎn)在于:在進(jìn)行加鎖和解鎖時(shí)需要非常地慎重。如果加鎖或者解鎖時(shí)機(jī)稍有一點(diǎn)偏差,就可能會(huì)引發(fā)重大問(wèn)題,然而這個(gè)問(wèn)題Java編譯器無(wú)法發(fā)現(xiàn),在進(jìn)行單元測(cè)試、集成測(cè)試時(shí)可能也發(fā)現(xiàn)不了,甚至程序上線(xiàn)后也能正常運(yùn)行,但是可能突然在某一天,它就莫名其妙地出現(xiàn)了。

  既然采用串行方式來(lái)訪(fǎng)問(wèn)共享資源這么容易出現(xiàn)問(wèn)題,那么有沒(méi)有其他辦法來(lái)解決呢?

  事實(shí)上,引起線(xiàn)程安全問(wèn)題的根本原因在于:多個(gè)線(xiàn)程需要同時(shí)訪(fǎng)問(wèn)同一個(gè)共享資源。

  假如沒(méi)有共享資源,那么多線(xiàn)程安全問(wèn)題就自然解決了,Java中提供的ThreadLocal機(jī)制就是采取的這種思想。

  然而大多數(shù)時(shí)候,線(xiàn)程間是需要使用共享資源互通信息的,如果共享資源在創(chuàng)建之后就完全不再變更,如同一個(gè)常量,而多個(gè)線(xiàn)程間并發(fā)讀取該共享資源是不會(huì)存在線(xiàn)上安全問(wèn)題的,因?yàn)樗芯€(xiàn)程無(wú)論何時(shí)讀取該共享資源,總是能獲取到一致的、完整的資源狀態(tài)。

  不可變對(duì)象就是這樣一種在創(chuàng)建之后就不再變更的對(duì)象,這種特性使得它們天生支持線(xiàn)程安全,讓并發(fā)編程變得更簡(jiǎn)單。

public class SynchronizedRGB {
 private int red; // 顏色對(duì)應(yīng)的紅色值
 private int green; // 顏色對(duì)應(yīng)的綠色值
 private int blue; // 顏色對(duì)應(yīng)的藍(lán)色值
 private String name; // 顏色名稱(chēng)
 
 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;
 }
}

  例如一個(gè)有個(gè)線(xiàn)程1執(zhí)行了以下代碼:

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

  然后有另外一個(gè)線(xiàn)程2在Statement 1之后、Statement 2之前調(diào)用了color.set方法:

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

  那么在線(xiàn)程1中變量myColorInt的值和myColorName的值就會(huì)不匹配。為了避免出現(xiàn)這樣的結(jié)果,必須要像下面這樣把這兩條語(yǔ)句綁定到一塊執(zhí)行:

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

  假如SynchronizedRGB是不可變類(lèi),那么就不會(huì)出現(xiàn)這個(gè)問(wèn)題,比如將SynchronizedRGB改成下面這種實(shí)現(xiàn)方式:

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方法并沒(méi)有改變?cè)瓉?lái)的對(duì)象,而是新創(chuàng)建了一個(gè)對(duì)象,所以無(wú)論線(xiàn)程1或者線(xiàn)程2怎么調(diào)用set方法,都不會(huì)出現(xiàn)并發(fā)訪(fǎng)問(wèn)導(dǎo)致的數(shù)據(jù)不一致的問(wèn)題。

2)消除副作用

  很多時(shí)候一些很?chē)?yán)重的bug是由于一個(gè)很小的副作用引起的,并且由于副作用通常不容易被察覺(jué),所以很難在編寫(xiě)代碼以及代碼review過(guò)程中發(fā)現(xiàn),并且即使發(fā)現(xiàn)了也可能會(huì)花費(fèi)很大的精力才能定位出來(lái)。

  舉個(gè)簡(jiǎn)單的例子:

class Person {
 private int age; // 年齡
 private String identityCardID; // 身份證號(hào)碼
 
 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));
    
    // 后續(xù)使用可能沒(méi)有察覺(jué)到j(luò)ack的age被修改了
    // 為后續(xù)埋下了不容易察覺(jué)的問(wèn)題
 
 }
 
 public static boolean validAge(Person person) {
 if (person.getAge() >= 100) {
  person.setAge(100); // 此處產(chǎn)生了副作用
  return false;
 }
 return true;
 }
 
}

  validAge函數(shù)本身只是對(duì)age大小進(jìn)行判斷,但是在這個(gè)函數(shù)里面有一個(gè)副作用,就是對(duì)參數(shù)person指向的對(duì)象進(jìn)行了修改,導(dǎo)致在外部的jack指向的對(duì)象也發(fā)生了變化。

  如果Person對(duì)象是不可變的,在validAge函數(shù)中是無(wú)法對(duì)參數(shù)person進(jìn)行修改的,從而避免了validAge出現(xiàn)副作用,減少了出錯(cuò)的概率。

3)減少容器使用過(guò)程出錯(cuò)的概率

  我們?cè)谑褂肏ashSet時(shí),如果HashSet中元素對(duì)象的狀態(tài)可變,就會(huì)出現(xiàn)元素丟失的情況,比如下面這個(gè)例子:

class Person {
 private int age; // 年齡
 private String identityCardID; // 身份證號(hào)碼
 
 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));
 
 }
}

輸出結(jié)果:

  所以在Java中,對(duì)于String、包裝器這些類(lèi),我們經(jīng)常會(huì)用他們來(lái)作為HashMap的key,試想一下如果這些類(lèi)是可變的,將會(huì)發(fā)生什么?后果不可預(yù)知,這將會(huì)大大增加Java代碼編寫(xiě)的難度。

三.如何創(chuàng)建不可變對(duì)象

  通常來(lái)說(shuō),創(chuàng)建不可變類(lèi)原則有以下幾條:

  1)所有成員變量必須是private

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

  3)不提供能夠修改原有對(duì)象狀態(tài)的方法

最常見(jiàn)的方式是不提供setter方法

如果提供修改方法,需要新創(chuàng)建一個(gè)對(duì)象,并在新創(chuàng)建的對(duì)象上進(jìn)行修改

  4)通過(guò)構(gòu)造器初始化所有成員變量,引用類(lèi)型的成員變量必須進(jìn)行深拷貝(deep copy)

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

  6)最好不允許類(lèi)被繼承(非必須)

  JDK中提供了一系列方法方便我們創(chuàng)建不可變集合,如:

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

  另外,在Google的Guava包中也提供了一系列方法來(lái)創(chuàng)建不可變集合,如:

ImmutableList.copyOf(list)

     這2種方式雖然都能創(chuàng)建不可變list,但是兩者是有區(qū)別的,JDK自帶提供的方式實(shí)際上創(chuàng)建出來(lái)的不是真正意義上的不可變集合,看unmodifiableList方法的實(shí)現(xiàn)就知道了:

可以看出,實(shí)際上UnmodifiableList是將入?yún)ist的引用復(fù)制了一份,同時(shí)將所有的修改方法拋出UnsupportedOperationException。

因此如果在外部修改了入?yún)ist,實(shí)際上會(huì)影響到UnmodifiableList,而Guava包提供的ImmutableList是真正意義上的不可變集合,它實(shí)際上是對(duì)入?yún)ist進(jìn)行了深拷貝??聪旅孢@段測(cè)試代碼的結(jié)果便一目了然:

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);
 
 }
 
}

輸出結(jié)果:

四.不可變對(duì)象真的"完全不可改變"嗎?

  不可變對(duì)象雖然具備不可變性,但是不是"完全不可變"的,這里打上引號(hào)是因?yàn)橥ㄟ^(guò)反射的手段是可以改變不可變對(duì)象的狀態(tài)的。

  大家看到這里可能有疑惑了,為什么既然能改變,為何還叫不可變對(duì)象?這里面大家不要誤會(huì)不可變的本意,從不可變對(duì)象的意義分析能看出來(lái)對(duì)象的不可變性只是用來(lái)輔助幫助大家更簡(jiǎn)單地去編寫(xiě)代碼,減少程序編寫(xiě)過(guò)程中出錯(cuò)的概率,這是不可變對(duì)象的初衷。如果真要靠通過(guò)反射來(lái)改變一個(gè)對(duì)象的狀態(tài),此時(shí)編寫(xiě)代碼的人也應(yīng)該會(huì)意識(shí)到此類(lèi)在設(shè)計(jì)的時(shí)候就不希望其狀態(tài)被更改,從而引起編寫(xiě)代碼的人的注意。下面是通過(guò)反射方式改變不可變對(duì)象的例子:

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);
 }
 
}

輸出結(jié)果:

以上就是詳解Java中的不可變對(duì)象的詳細(xì)內(nèi)容,更多關(guān)于Java中的不可變對(duì)象的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • mybatis源碼解讀之executor包懶加載功能?

    mybatis源碼解讀之executor包懶加載功能?

    這篇文章主要介紹了mybatis源碼解讀之executor包懶加載功能,mybatis的懶加載的實(shí)現(xiàn)由executor包的loader子包支持,下面文章詳細(xì)內(nèi)容需要的小伙伴可以參考一下
    2022-02-02
  • Swing常用組件之多行文本區(qū)JTextArea

    Swing常用組件之多行文本區(qū)JTextArea

    這篇文章主要為大家詳細(xì)介紹了Swing常用組件之多行文本區(qū)JTextArea,感興趣的朋友可以參考一下
    2016-05-05
  • SpringMVC攔截器的實(shí)現(xiàn)和作用及Redis登陸功能的優(yōu)化詳解

    SpringMVC攔截器的實(shí)現(xiàn)和作用及Redis登陸功能的優(yōu)化詳解

    這篇文章主要介紹了Java項(xiàng)目SpringMVC攔截器+Redis優(yōu)化登錄功能實(shí)現(xiàn)過(guò)程,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)吧
    2022-09-09
  • 圖文詳解如何將java編寫(xiě)的程序轉(zhuǎn)為exe文件

    圖文詳解如何將java編寫(xiě)的程序轉(zhuǎn)為exe文件

    我們寫(xiě)的程序,要讓小伙伴打開(kāi)即用,可以將java程序生成可執(zhí)行文件,下面這篇文章主要給大家介紹了關(guān)于一步步教你如何將java編寫(xiě)的程序轉(zhuǎn)為exe文件的相關(guān)資料,需要的朋友可以參考下
    2023-01-01
  • Java正則判斷日期格式是否正確的方法示例

    Java正則判斷日期格式是否正確的方法示例

    這篇文章主要介紹了Java正則判斷日期格式是否正確的方法,結(jié)合實(shí)例形式分析了Java針對(duì)日期字符串正則判斷的相關(guān)操作技巧,需要的朋友可以參考下
    2017-03-03
  • 聊聊Controller中RequestMapping的作用

    聊聊Controller中RequestMapping的作用

    這篇文章主要介紹了Controller中RequestMapping的作用,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2022-02-02
  • Spring Boot整合Spring Data Jpa代碼實(shí)例

    Spring Boot整合Spring Data Jpa代碼實(shí)例

    這篇文章主要介紹了Spring Boot整合Spring Data Jpa代碼實(shí)例,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下
    2019-11-11
  • Java并發(fā)編程中的volatile關(guān)鍵字詳解

    Java并發(fā)編程中的volatile關(guān)鍵字詳解

    這篇文章主要介紹了Java并發(fā)編程中的volatile關(guān)鍵字詳解,volatile?用于保證我們某個(gè)變量的可見(jiàn)性,使其一直存放在主存中,不被移動(dòng)到某個(gè)線(xiàn)程的私有工作內(nèi)存中,需要的朋友可以參考下
    2023-08-08
  • 帶你快速搞定java多線(xiàn)程

    帶你快速搞定java多線(xiàn)程

    這篇文章主要介紹了java多線(xiàn)程編程實(shí)例,分享了幾則多線(xiàn)程的實(shí)例代碼,具有一定參考價(jià)值,加深多線(xiàn)程編程的理解還是很有幫助的,需要的朋友可以參考下
    2021-07-07
  • Java安全框架——Shiro的使用詳解(附springboot整合Shiro的demo)

    Java安全框架——Shiro的使用詳解(附springboot整合Shiro的demo)

    這篇文章主要介紹了Java安全框架——Shiro的使用詳解,幫助大家更好的理解和學(xué)習(xí)使用Shiro,感興趣的朋友可以了解下
    2021-04-04

最新評(píng)論