引自：
http://www.mengyan.org/blog/archives/2004/08/14/87.htmlThese days, when I’m reading some other guy’s code, I encounter some problem. In these code, I can read following codes:
- JButton button = new JButton("OK");
- button.setActionCommand("OK");
- button.addActionListener(this);
- ......
- actionPerformed(e) {
- String s = e.getActionCommand();
- if(s=="OK")
- ......
- }
Look, it use “==” but not “equals” here. “Oh, it must be a bug!”, I told myself. But, wait, when I excuted the program, it worked quite well. And till this moment, I remembered, current powerful JVM will maintain a constant pool for String, so maybe two “OK” will reference the same place. So, such mechanism will work.
But, does Java Language Specification has such standard? and all JVM will follow this standard? I continue to dig into it.
First, I found such item in JLS 3.10.5 — String literals.
Abstract some points here:
Literal strings within the same class ($8) in the same package ($7) represent references to the same String object ($4.3.1).
Literal strings within different classes in the same package represent references to the same String object.
Literal strings within different classes in different packages likewise represent references to the same String object.
Strings computed by constant expressions ($15.28) are computed at compile time and then treated as if they were literals.
Strings computed at run time are newly created and therefore distinct.
The result of explicitly interning a computed string is the same string as any pre-existing literal string with the same contents.
So, this is the feature of String class, every JVM should follow. And, when I read the code of String.java, I found such comments in method “intern“.
public String intern()
Returns a canonical representation for the string object.
A pool of strings, initially empty, is maintained privately by the class String.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~So good:-)
When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.
It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.
All literal strings and string-valued constant expressions are interned. String literals are defined in $3.10.5 of the Java Language Specification.
It’s quite clear about the case I encountered. Then I understand, this is not a bug, but the trick 
. But, why he use “==” but not “equals“, I think that will be more clear and more easy to read, I think there must be other guys to be puzzled as me 
.
I think the author must care more about the performance than the code, the performance of “==” sure if better than “equals“, especially when the String is long~.
Ok, everything clear now, and sure, not only String has such pool. For example:
- Integer i = 1;
- Integer j = 1;
what will System.out.println(i==l) output? I think you can get the right answer.
Update (2005.11.09):
"String"’s method "equalsIgnoreCase" also take advantage of this string pool:
- public boolean equalsIgnoreCase(String anotherString) {
- return (this == anotherString) ? true :
- (anotherString != null) && (anotherString.count == count) &&
- regionMatches(true, 0, anotherString, 0, count);
- }
If the two string point the same one, simply return true.
So, if you need to compare Strings frequently, you should "Intern" them.
For example, in Lucene’s source code, you need to compare the Field name very often, so, they intern the field name.
- this.name = name.intern(); // field names are interned
Popularity: 9%
This entry was posted on Saturday, August 14th, 2004 at 5:25 pm and is filed under 技术. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.