blocks|key|2887887|text|正如您在内部所说的，最后一个连接是对类似于|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2887888|String+e+=+new+StringBuilder().append(c).append("ender").toString();|code-block|syntax|javascript|2887889|StringBuilder+的toString()实现创建了一个新的字符串。下面是实现。|offset|length|style|CODE|BOLD|2887890|public+String+toString()+{
+++++//+Create+a+copy,+don't+share+the+array
+++++return+new+String(value,+0,+count);
}|2887891|仅当两个字符串是相同的true时，使用==而不是.equals()+比较字符串才会返回。在本例中，因为第二个字符串是作为String.类型的新对象创建的，所以它们不同|2887892|其他连接是由编译器直接执行的，因此不会创建新的字符串。|2887893|entityMap^0|0|0|0|D|F|A|E|N|0|0|B|4|Y|9|1O|6|B|4|J|2|O|9|1O|6|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|W|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|X|8|@$I|Y|J|Z|K|L]|$I|10|J|11|K|L]|$I|12|J|13|K|M]]|9|@]|A|$]]|$1|N|3|O|5|D|7|14|8|@]|9|@]|A|$E|F]]|$1|P|3|Q|5|6|7|15|8|@$I|16|J|17|K|M]|$I|18|J|19|K|M]|$I|1A|J|1B|K|M]|$I|1C|J|1D|K|L]|$I|1E|J|1F|K|L]|$I|1G|J|1H|K|L]|$I|1I|J|1J|K|L]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1K|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|U|$]]

As you said internally the last concatenation is done to something similar to

<pre><code>String e = new StringBuilder().append(c).append("ender").toString();
</code></pre>

the implementation of <code>toString()</code> of <code>StringBuilder</code> creates a new String. Here is the implementation.

<pre><code>public String toString() {
 // Create a copy, don't share the array
 return new String(value, 0, count);
}
</code></pre>

Comparing strings using <code>==</code> instead of <code>.equals()</code> returns <code>true</code> only if both strings are the same. In this case they are not the same because the second string is created as a new object of type <code>String</code>.

The other concatenations are performed directly by the compiler so no new String is created.

blocks|key|121444|text|有四件事正在发生：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|121445|121446|(您很清楚这一点，但是对于潜伏者)+==测试以查看变量是否指向same+object，而不是等价的字符串。因此，即使x为"foo"，y也为"foo"，x+==+y也可能为真或假，这取决于x和y引用的是同一个String对象还是不同的对象。这就是为什么我们使用equals而不是==来比较字符串的等价性。以下所有内容只是为了解释为什么==有时是真的，并不建议使用==来比较字符串。相同类中的:-)|ordered-list-item|offset|length|style|CODE|BOLD|121447|Equivalent字符串常量(根据JLS中的各种规则，编译器知道它们是常量)由编译器引用相同的字符串(编译器还在类的"constant+pool"中列出它们)。这就是a+==+b为true的原因。|121448|当装入类时，它的每个字符串常量都会自动为-检查JVM的字符串池中是否有等价的字符串，如果找到，则使用该String对象(如果没有找到，则将新常量的新String对象添加到池中)。因此，即使x是在Foo类中初始化的字符串常量，y是在Bar类中初始化的字符串常量，它们也会相互==。|121449|121450|上面的第2点和第3点在JLS§3.10.5中有所涉及。(关于类常量池的部分是实现细节，因此前面提供了到JVM规范的链接；JLS只是说如果处理常量值，interning.)|121451|The编译器就会进行字符串连接，所以|unordered-list-item|121452|121453|String+d=+"dev“%2B+"ender"；|121454|被编译为|121455|String+d=+"devender"；|121456|"devender"是一个字符串常量，编译器和JVM将上面的第2点和第3点应用于它。例如，没有使用StringBuilder，则串联发生在编译时，而不是运行时。这在JLS§15.28+-+中有介绍。因此，a+==+d为true的原因与a+==+b为true的原因相同:它们引用相同的常量字符串，因此编译器确保它们引用类的常量池中的相同字符串。|121457|当任何一个操作数不是常量时，编译器不能这样做，所以它不能这样做：|121458|字符串e=c%2B+"ender"；|121459|...even虽然代码分析可以很容易地显示c的值肯定是"dev"，因此e肯定是"devender"。该规范只让编译器使用常量值进行连接，特别是。因此，由于编译器无法做到这一点，它将输出您引用的StringBuilder代码，并在运行时创建一个新的String对象。该字符串不会自动内嵌，因此e最终引用了与a不同的String对象，因此a+==+e为false。|121460|请注意，如果您将c声明为final，则as+Vinod+said：|121461|最后一个字符串c=+"dev"；|121462|然后它将是一个+(是的，它们确实是这样叫的)，因此将应用§15.28，编译器将|121463|字符串e=c%2B+"ender"；|121464|转到|121465|字符串e=+"devender"；|121466|：a+==+e也是真的。|121467|只是重申一下:这并不意味着我们应该使用==来比较字符串的等价性。:-)这就是equals的作用。|121468|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/8/docs/api/java/lang/String.html#equals-java.lang.Object-|1|https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4|2|https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.5|3|https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.28|4|https://stackoverflow.com/questions/34509566/in-case-of-string-concatenation-in-java/34509659#comment56760592_34509566^0|0|0|I|2|1M|1|1O|5|1U|1|1X|5|23|6|2L|1|2N|1|2V|6|3L|6|3U|2|4M|2|50|2|V|4|10|6|3L|6|0|0|2C|6|1N|F|1|0|1F|6|22|6|2M|1|2P|3|34|1|37|3|3S|2|0|0|B|A|2|0|0|0|0|0|0|0|A|1D|D|2U|6|39|6|2A|C|3|0|0|0|L|1|R|5|Z|1|13|A|2O|D|3F|6|41|1|48|1|4C|6|4N|6|0|8|1|C|5|J|D|4|0|0|0|0|0|0|1|6|0|J|2|12|6|0^^$0|@$1|2|3|4|5|6|7|25|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|27|8|@$F|28|G|29|H|I]|$F|2A|G|2B|H|I]|$F|2C|G|2D|H|I]|$F|2E|G|2F|H|I]|$F|2G|G|2H|H|I]|$F|2I|G|2J|H|I]|$F|2K|G|2L|H|I]|$F|2M|G|2N|H|I]|$F|2O|G|2P|H|I]|$F|2Q|G|2R|H|I]|$F|2S|G|2T|H|I]|$F|2U|G|2V|H|I]|$F|2W|G|2X|H|I]|$F|2Y|G|2Z|H|J]|$F|30|G|31|H|J]]|9|@$F|32|G|33|1|34]]|A|$]]|$1|K|3|L|5|E|7|35|8|@$F|36|G|37|H|I]]|9|@$F|38|G|39|1|3A]]|A|$]]|$1|M|3|N|5|E|7|3B|8|@$F|3C|G|3D|H|I]|$F|3E|G|3F|H|I]|$F|3G|G|3H|H|I]|$F|3I|G|3J|H|I]|$F|3K|G|3L|H|I]|$F|3M|G|3N|H|I]|$F|3O|G|3P|H|I]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|3Q|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|3R|8|@]|9|@$F|3S|G|3T|1|3U]]|A|$]]|$1|R|3|S|5|T|7|3V|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|3W|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|3X|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|3Y|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|3Z|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|40|8|@$F|41|G|42|H|I]|$F|43|G|44|H|I]|$F|45|G|46|H|I]|$F|47|G|48|H|I]]|9|@$F|49|G|4A|1|4B]]|A|$]]|$1|13|3|14|5|6|7|4C|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|4D|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|4E|8|@$F|4F|G|4G|H|I]|$F|4H|G|4I|H|I]|$F|4J|G|4K|H|I]|$F|4L|G|4M|H|I]|$F|4N|G|4O|H|I]|$F|4P|G|4Q|H|I]|$F|4R|G|4S|H|I]|$F|4T|G|4U|H|I]|$F|4V|G|4W|H|I]|$F|4X|G|4Y|H|I]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|4Z|8|@$F|50|G|51|H|I]|$F|52|G|53|H|I]]|9|@$F|54|G|55|1|56]]|A|$]]|$1|1B|3|1C|5|6|7|57|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|58|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|59|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|5A|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|5B|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|5C|8|@$F|5D|G|5E|H|I]]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|5F|8|@$F|5G|G|5H|H|I]|$F|5I|G|5J|H|I]]|9|@]|A|$]]|$1|1P|3|-4|5|6|7|5K|8|@]|9|@]|A|$]]]|1Q|$1R|$5|1S|1T|1U|A|$1V|1W]]|1X|$5|1S|1T|1U|A|$1V|1Y]]|1Z|$5|1S|1T|1U|A|$1V|20]]|21|$5|1S|1T|1U|A|$1V|22]]|23|$5|1S|1T|1U|A|$1V|24]]]]

Four things are going on:

<ol>
<li>(You clearly know this, but for lurkers) <code>==</code> tests to see if the variables point to the same <code>String</code> object, not equivalent strings. So even if <code>x</code> is <code>"foo"</code> and <code>y</code> is also <code>"foo"</code>, <code>x == y</code> may be true or false, depending on whether <code>x</code> and <code>y</code> refer to the same <code>String</code> object or different ones. That's why we use <a href="http://docs.oracle.com/javase/8/docs/api/java/lang/String.html#equals-java.lang.Object-" rel="nofollow noreferrer"><code>equals</code></a>, not <code>==</code>, to compare strings for equivalence. All of the following is just meant to explain why <code>==</code> is sometimes true, it's not a suggestion to use <code>==</code> to compare strings. :-)</li>
<li>Equivalent string constants (strings the compiler knows are constants according to various rules in the JLS) within the same class are made to refer to the same string by the compiler (which also lists them in the class's <a href="https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4" rel="nofollow noreferrer">"constant pool"</a>). That's why <code>a == b</code> is true.</li>
<li>When the class is loaded, each of its string constants is automatically <a href="http://docs.oracle.com/javase/8/docs/api/java/lang/String.html#intern--" rel="nofollow noreferrer">interned</a>&nbsp;&mdash; the JVM's string pool is checked for an equivalent string and if one is found, that <code>String</code> object is used (if not, the new <code>String</code> object for the new constant is added to the pool). So even if <code>x</code> is a string constant initialized in class <code>Foo</code> and <code>y</code> is a string constant initialized in class <code>Bar</code>, they'll be <code>==</code> each other.

Points 2 and 3 above are covered in part by <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.5" rel="nofollow noreferrer">JLS§3.10.5</a>. (The bit about the class constant pool is a bit of an implementation detail, hence the link to the JVM spec earlier; the JLS just speaks of interning.)</li>
<li>The compiler does string concatenation if it's dealing with constant values, so 

<pre><code>String d = "dev" + "ender";
</code></pre>

is compiled to

<pre><code>String d = "devender";
</code></pre>

and <code>"devender"</code> is a string constant the compiler and JVM apply points 2 and 3 above to. E.g., no <code>StringBuilder</code> is used, the concatenation happens at compile-time, not runtime. This is covered in <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.28" rel="nofollow noreferrer">JLS§15.28 - Constant Expressions</a>. So <code>a == d</code> is true for the same reason <code>a == b</code> is true: They refer to the same constant string, so the compiler ensured they were referring to the same string in the class's constant pool.

The compiler can't do that when any of the operands is not a constant, so it can't do that with:

<pre><code>String e = c + "ender";
</code></pre>

...even though code analysis could easily show that the value of <code>c</code> will definitely be <code>"dev"</code> and thus <code>e</code> will definitely be <code>"devender"</code>. The specification only has the compiler do the concatenation with constant values, specifically. So since the compiler can't do it, it outputs the <code>StringBuilder</code> code you referred to and that work is done at runtime, creating a new <code>String</code> object. That string isn't automatically interned, so <code>e</code> ends up referring to a different <code>String</code> object than <code>a</code> does, and so <code>a == e</code> is false.

Note that <a href="https://stackoverflow.com/questions/34509566/in-case-of-string-concatenation-in-java/34509659#comment56760592_34509566">as Vinod said</a>, if you declared <code>c</code> as <code>final</code>:

<pre><code>final String c = "dev";
</code></pre>

Then it would be a <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12.4" rel="nofollow noreferrer">constant variable</a> (yes, they're really called that) and so §15.28 would apply and the compiler would turn

<pre><code>String e = c + "ender";
</code></pre>

into

<pre><code>String e = "devender";
</code></pre>

and <code>a == e</code> would also be true.</li>
</ol>

Just to reiterate: None of which means we should use <code>==</code> to compare strings for equivalence. :-) That's what <code>equals</code> is for.

blocks|key|123514|text|"dev"+%2B+"ender"是一个编译时可计算的常量表达式:两个参数都是字符串文字。因此，该表达式为"devender"。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|123515|对于c+%2B+"ender"则不能这样说:某些情况(例如，在不同线程上运行的一些代码)可能会导致c被设置为不同的值。将c限定为final可以避免这种可能性，在这种情况下，e也会引用与a相同的对象。|123516|因此，a、b和d都引用同一个对象。|123517|entityMap^0|0|F|1F|A|0|2|B|1B|1|1M|1|1Q|5|2C|1|2I|1|0|3|1|5|1|7|1|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|K|$]]

<code>"dev" + "ender"</code> is a compile-time evaluable constant expression: both arguments are string literals. The expression is therefore <code>"devender"</code>.

The same cannot be said for <code>c + "ender"</code>: certain circumstances (some code running on a different thread for example) could lead to <code>c</code> being set to a different value. Qualifying <code>c</code> as <code>final</code> obviates this possibility, and in that case <code>e</code> would also refer to the same object as <code>a</code>.

So <code>a</code>, <code>b</code>, and <code>d</code> all refer to the same object.

blocks|key|120746|text|d和e之间的区别在于，当您连接字符串文字时，连接是在编译时执行的。Java编译器以与"devender"表达式相同的方式处理"dev"+%2B+"ender"表达式，在编译时产生相同的文字。由于所有的String文本都会被内嵌，因此"dev"+%2B+"ender"的结果d最终也会引用与a和b的"devender"相同的对象。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|120747|e的表达式是c+%2B+"ender"，它在运行时计算。即使它生成相同的字符串，编译器也不会使用这一事实。这就是为什么会生成一个不同的String对象，从而导致==上的比较失败。|120748|entityMap^0|0|1|2|1|16|A|1Q|F|2Q|6|36|F|3O|1|3W|1|3Y|1|40|A|0|0|1|6|B|1T|6|26|2|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]]|I|$]]

The difference between <code>d</code> and <code>e</code> is that when you concatenate string literals, the concatenation is performed at compile time. Java compiler treats <code>"dev" + "ender"</code> expression in the same way as <code>"devender"</code> expression, producing the same literal at compile time. Since all <code>String</code> literals get interned, <code>d</code>, which is a result of <code>"dev" + "ender"</code>, also ends up referencing the same object as <code>a</code> and <code>b</code>'s <code>"devender"</code>. 

The expression for <code>e</code>, which is <code>c + "ender"</code>, is evaluated at runtime. Even though it produces the same string, this fact is not used by the compiler. That's why a different <code>String</code> object is produced, resulting in failed comparison on <code>==</code>.

blocks|key|123407|text|编译器在幕后做了很多优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|123408|123409|字符串d=+"dev“%2B+"ender"；|blockquote|123410|123411|123412|在这里，当编译程序时，编译器会用"devender"替换"dev"+%2B+"ender"。如果您要添加2个文字(这适用于原语和字符串)，编译器将执行此优化。|offset|length|style|CODE|123413|Java代码：|123414|String+d+=+"dev"+%2B+"ender";|code-block|syntax|javascript|123415|字节码：|123416|++0:+ldc+++++++++++#16+++++++++++++++++//+String+devender|123417|到了一个特殊的情况：|123418|123419|最终字符串c=+"dev"；//标记为最终字符串e=c%2B+"ender"；|123420|123421|123422|将c设为final将使字符串成为编译时间常量。编译器将意识到c的值不能改变，因此在编译时将所有出现的c替换为"dev“值，因此e将在编译时本身解析。|123423|entityMap^0|0|0|0|0|0|G|A|S|F|0|0|0|0|0|0|0|0|0|0|1|1|U|1|1E|1|1R|1|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1B|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@$J|1F|K|1G|L|M]|$J|1H|K|1I|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1J|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1K|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|1L|8|@]|9|@]|A|$]]|$1|W|3|X|5|R|7|1M|8|@]|9|@]|A|$S|T]]|$1|Y|3|Z|5|6|7|1N|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|11|3|12|5|E|7|1P|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1S|8|@$J|1T|K|1U|L|M]|$J|1V|K|1W|L|M]|$J|1X|K|1Y|L|M]|$J|1Z|K|20|L|M]]|9|@]|A|$]]|$1|17|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|18|$]]

The compiler does a lot of optimisation under the hood.

<blockquote>
<pre><code>String d = "dev" + "ender";
</code></pre>
</blockquote>

Here the compiler will replace <code>"dev" + "ender"</code> with <code>"devender"</code> when the program is being compiled. If you are adding 2 literals (this applies to both primitives as well as Strings), the compiler does this optimisation. 

Java code :

<pre><code>String d = "dev" + "ender";
</code></pre>

Byte code :

<pre><code> 0: ldc #16 // String devender
</code></pre>

Coming to a special case :

<blockquote>
<pre><code>final String c = "dev"; // mark this as final
String e = c + "ender";
</code></pre>
</blockquote>

Making <code>c</code> final will make the String a compile-time-constant. The compiler will realize that the value of <code>c</code> cannot change and hence will replace all occurances of <code>c</code> with the value "dev" when compiling, thus <code>e</code> will be resolved during compile time itself.

blocks|key|120770|text|字符串d=+"dev“%2B”one“；常量%2B常量，‘d’仍然是常量(同一个)，所以(a+==+d)为真；|type|unstyled|depth|inlineStyleRanges|entityRanges|data|120771|字符串e=c%2B“and”；变量%2B常量，结果'e‘是一个变量，它会在内部使用StringBuilder，并创建一个新的引用。|120772|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

String d = "dev" + "ender"; constant + constant, ‘d’ is still a constant(the same one), so (a == d) is true;

String e = c + "ender"; variable + constant, the result 'e' is a variable, it will use StringBuilder internally,and create a new reference.

blocks|key|2888311|text|请记住，Java持有在程序中找到的所有字符串文字的池，用于匹配等目的，因此上面的任何不同的字符串文字连接都将导致相同的对象，相同的字符串文字。您可以查看this有用的文章以获取更多信息。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2888312|另一方面，String对象和文本(case+c+%2B+"ender")的连接将导致在运行时创建as+StringBuilder对象，这与池中的文本不同。|CODE|2888313|entityMap|0|LINK|mutability|MUTABLE|url|http://www.xyzws.com/javafaq/what-is-string-literal-pool/3^0|1C|2|24|4|0|0|5|6|M|B|1D|D|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@$9|T|A|U|1|V]]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|H]|$9|Z|A|10|B|H]|$9|11|A|12|B|H]]|D|@]|E|$]]|$1|I|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|J|$K|$5|L|M|N|E|$O|P]]]]

Keep in mind that Java holds a pool of all string literals found in program, used for matching purposes among others, so any different string literal concatenation above will lead to the same object, to the same string literal. You can check out <a href="http://www.xyzws.com/javafaq/what-is-string-literal-pool/3" rel="nofollow">this</a> useful article for more.

On the other hand, the concatenation of a <code>String</code> object and a literal (case <code>c + "ender"</code>) will lead to the creation of a as <code>StringBuilder</code> object at runtime, different to the literals found in pool.

<pre><code>String a = &quot;devender&quot;;
String b = &quot;devender&quot;;
String c = &quot;dev&quot;;
String d = &quot;dev&quot; + &quot;ender&quot;;
String e = c + &quot;ender&quot;;

System.out.println(a == b); //case 1: o/p true

System.out.println(a == d); //case 2: o/p true

System.out.println(a == e); //case 3: o/p false
</code></pre>
a &amp; b both are pointing to the same String Literal in string constant pool. So <code>true</code> in case 1
<pre><code>String d = &quot;dev&quot; + &quot;ender&quot;;
</code></pre>
should be internally using something like:
<pre><code>String d = new StringBuilder().append(&quot;dev&quot;).append(&quot;ender&quot;).toString();
</code></pre>
How a &amp; d are pointing to the same reference &amp; not a &amp; e ?

"==" in case of String concatenation in Java

String a = "devender";String b = "devender";String c = "dev";String d = "dev" + "ender";String e = c + "ender";System.out.println(a == b);     //case 1: o/p tru...

问在Java中连接字符串时使用"==“
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中连接字符串时使用"==“EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中连接字符串时使用"==“
EN