[jfriends-ml 11402] Re: Java 1.5 Tiger : A Developer's Notebook

[murayama <locutus@xxxxxxxxxxxxxxxx>]

村山@netgeneです．

> 厳密には、キャッシュというより intern ですね。
いや，キャッシュはキャッシュだと思います．
String#intern()は一意性を保証しますので．
＃つまりintern()の結果同士ではequlals()と==とが同じ結果になる．

こっちは一意性を保証しません．

> intern という目的からすると、SoftReference でキャッシュしておくの
> は「GC されないこと」＝「他に使用している箇所があること」なのでコ
> スト増は少ないと考えられます。(SoftReference 自体の領域が無駄なの
> で現実にはそうでもないですが^^;)
ここで言うコストはメモリ消費程度を意味すると思いますが，実際には
一意性を保証するコストの方が危険だと思います．本質的に同期処理です
からね．それこそデュアルコアとかだと，どんな副作用が出るか分かった
ものじゃありません．

一意性を保証する必要がなければ，それを使った様々な最適化(或いは
「手抜き」)が可能です．「一意性を保証する」という仕様があると，
その仕様自体がボトルネックになる可能性があります．

> # ついでに、常に == であることを保証しようと思ったらそもそも new 
> # できてはいけないわけですが。
String#intern()の結果がこれですよ．

> ところでこういう仕様が普及し、この仕様を前提にプログラミングを始
> める人が増えてくると、== での比較がますます危険になり(int と 
> Integer のコンテキストの意識が希薄になると == は危険になってくるで
> しょうから)、初心者は皆 equals を使うようになりそう。
> そうすると、primitive の比較もみんな boxing が実行されるようにな
> り、効率が下がる、と。
むしろ問題はプリミティブ型が使える全ての場所でIntegerを使おうという
方の危険性ですね．boxing/unboxingは記述を簡単にするだけで，その本質
的なコストは何ら変わっていないという認識は必要です．

これはStringの足し算が（あまりに頻繁に行う場合は）コストであるという
のと同様．