2015-10-28 42 views
-3

我的問題是關於字符串不可變性和字符串常量池。 是否有效內存效率Java設計人員已經實現了String常量池,爲了支持它,他們讓String對象不可變。 或者他們想要爲其他任何原因(例如線程安全性,安全性等)提供不可變性,然後爲了避免不可變性的缺陷(對於每次更改,都會創建新對象,並且在多個字符串操作期間內存效率低下)他們提供字符串常量池的哪個先到?字符串不可變性或字符串常量

的概念,總之什麼Java的設計者,不變性或字符串常量池的

+2

如何永恆事業「創建大量重複對象的」?通常情況恰恰相反:所有東西都是不可變的 - >所有東西都可以安全地在線程間共享=>不需要進行防禦性複製。 –

+1

這是舊的「雞或蛋」問題。它們不一定首先出現,它們一起演變。雖然在這種情況下,我會說(的意見!)那'String'不變性來到第一,用'Character','Boolean','Byte','Short','Integer','Long','Float'在一起,'Double','BigInteger'和'BigDecimal',但不幸的不是Date。通過不可變的'String',常量池成爲可能。 – Andreas

+0

感謝安德烈Tyukin您指出有關的錯誤「重複的對象......」我的意思是說在String對象的變化將導致創建新的對象是在大量的字符串操作的情況下,效率不高。問題相應地改變 – SandeepT

回答

3

Immutability was the driver.詹姆斯·高斯林(Java的主要設計者)是不可改變的忠實信徒的心中首先出現。

Bill Venners:那不可變的怎麼樣?我應該什麼時候使用immutables和non-immutables?

James Gosling:我會盡可能使用不可變的。

Bill Venners:只要你可以,爲什麼?

詹姆斯高斯林:從戰略角度來看,他們往往更容易麻煩。通常你可以用不可變的東西來做些事情,你不能用可變的東西來做,比如緩存結果。如果將字符串傳遞給文件打開方法,或者將字符串傳遞給用戶界面中標籤的構造函數,則在某些API中(如許多Windows API中)傳遞一組字符。該對象的接收者實際上必須複製它,因爲他們不知道關於它的存儲生命週期的任何信息。他們不知道這個物體發生了什麼,它是否正在腳下改變。

你最終幾乎被迫複製對象,因爲你不知道你是否擁有它。關於不可改變的對象的好處之一是答案是,「是的,當然你是。」因爲所有權問題,誰有權改變它,並不存在。

將字符串強制爲不可變的事情之一是安全性。你有一個文件打開方法。你傳遞一個字符串給它。然後它會在進行操作系統調用之前進行各種身份驗證檢查。如果你設法做一些有效改變字符串的東西,在安全檢查之後,在OS調用之前,然後繁榮,你就會進入。但字符串是不可改變的,所以這種攻擊是行不通的。這個確切的例子是真正要求字符串是不可變的。

字符串常量池只是不變性如何有用的一個例子。

,然後爲了避免不變性(創建大量重複的對象造成內存效率低下)的缺點,他們提供的字符串常量池的

這是沒有意義的概念。不變性減少您在內存中需要的重複對象的數量;字符串常量池就是一個很好的例子。

不變性意味着你有更多的臨時對象,而不是重複的對象。臨時對象很容易垃圾收集。

+0

由於我知道不變性意味着一旦創建,一個String對象不能被改變。並說「然後以避免不可改變的缺點(很多重複對象的創建導致內存效率低下),他們提供的字符串常量池中的理念,以」我的意思是說在String對象的變化將導致新對象的創建是如果在這種意義上的大量字符串操作的情況下效率低下,我認爲這是一個缺點 – SandeepT

+0

@SandeepT:是的。那些不是**重複的**對象。再次,臨時對象很容易被GC'd。 –