2010-07-29 56 views
6

最近審查一些Java Swing代碼,看到這一點:是否將字符串封裝爲字節[]以節省內存過量使用? (JAVA)

byte[] fooReference; 

String getFoo() { 
    returns new String(fooReference); 
} 

void setFoo(String foo) { 
    this.fooReference = foo.getBytes(); 
} 

上面可以節省你的內存佔用有用或因此我告訴。

這種矯枉過正是否有人用這種方式封裝了它們的字符串?

+1

除非你存儲數千兆或字符串的演出的話,我根本不會去想這樣做 – 2010-07-29 22:17:15

回答

31

這是一個真的,真的糟糕的主意。不要使用平臺默認編碼。沒有什麼可以說,如果您撥打setFoo,然後getFoo,您將獲得相同的數據。

如果你必須做這樣的事情,然後使用UTF-8,它可以代表整個Unicode的確定......但我真的不會這樣做。它潛在的節省了一些內存,但是在大多數時間不必要地執行轉換 - 並且容易出錯,無法使用適當的編碼。

我敢說有一些應用程序,如果這是適當的,但99.99%,這是一個可怕的想法。

+1

,這就是即使假設把它作爲字節和每一個它的訪問時間來創建一個新的字符串是在第一個好主意地點。 – 2010-07-29 22:16:45

+0

@mmyers:我越來越喜歡:) – 2010-07-29 22:17:01

+0

這可能是他使用字符集選項,不記得 - 即使如此,它似乎是一個不受歡迎的想法。很高興我問。 – JamesC 2010-07-29 22:29:34

10

這是不是真的有用:
1.您每次複製或調用getFoo setFoo調用時字符串,因此增加CPU和內存使用率
2.它是不起眼的

3

這可能是矯枉過正,它甚至可能消耗更多的內存,因爲你現在有兩個字符串的副本。實際字符串的生存時間取決於客戶端,但正如許多這樣的黑客一樣,它聽起來很像過早的優化。

+0

使用的情況是在一個擺動客戶端緩存。被告知在JTable中,這將節省內存。 – JamesC 2010-07-29 22:17:44

1

如果在分析代碼後發現內存使用字符串是一個問題,那麼最好使用通用字符串壓縮器並存儲壓縮字符串,而不是嘗試爲未成年人使用UTF-8字符串減少他們給你的空間。對於英文字符串,通常可以將它們壓縮到每個字符1-2位;大多數其他語言可能類似。如果你有很多數據,每個角色1位很難,但是可能。

3

如果你預計你會有很多相同的字符串,另一種更好的方式可以節省內存是String.intern()方法。

2

每次調用getFoo()都會實例化一個新的String。這是如何節省內存?如果有什麼東西給垃圾回收器添加額外的開銷,並在這些新引用變爲未引用時清理這些新實例

2

這確實沒有任何意義。如果編譯時間常數不需要按回String,那麼它會使更有意義。你仍然有字符編碼問題。

對我來說,如果它是一個char[]常數,這會更有意義。在現實世界中,有幾個JSP編譯器將字符串常量優化爲char[],而這些編譯器又可以很容易地寫入Writer#write(char[])。這樣做的效果稍微「略微」了一些,但這些小小的內容在大型和大量使用的應用程序(如Google搜索等)中都佔據了很重要的位置。

Tomcat的JSP編譯器Jasper也這樣做。檢查genStringAsCharArray設置。然後,它確實喜歡這麼

static final char[] text1 = "some static text".toCharArray(); 

代替

static final String text1 = "some static text"; 

與更少的開銷結束。它並不需要圍繞這些字符的整個String實例。

5

有點歷史遊...

使用字節數組,而不是字符串對象實際使用有一些相當大的優勢在Java中(1.0/1.1)的初期,如果你能確保你永遠不會需要ISO-8859-1之外的任何東西。與那時的虛擬機相比,drawBytes()與drawString()相比使用速度提高了10倍以上,並且實際上確實節省了當時仍然非常稀少的內存,並且小程序用來具有32的硬編碼內存屏障,反正以後64 MB。不僅是比String對象的嵌入字符[]更小的字節[],而且還可以保存相對較重的字符串對象本身,如果您有很多短字符串,那麼確實會產生相當大的差異。除了訪問一個普通的字節數組的速度還要快於使用String的訪問器方法和所有額外的邊界檢查。

但是由於drawBytes在Java 1.2中不再更快,並且由於當前的JIT比那時的Symantec JIT好得多,所以byte []數組在字符串方面的最小性能優勢再也不值得麻煩了。記憶力優勢仍然存在,因此在一些非常罕見的極端情況下它仍然是一種選擇,但是現在如果沒有必要,沒有什麼應該考慮的。

相關問題