blocks|key|241009|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|241010|使用StringBuilder的目的，即减少内存。它实现了吗？|blockquote|241011|241012|241013|没关系，您请。该代码没有正确使用StringBuilder。(我认为您错误地引用了它；id2和table周围肯定没有引用？)|offset|length|style|CODE|241014|请注意，目标(通常)是减少内存混乱，而不是总内存使用量，以使垃圾收集器的工作变得更容易。|241015|241016|会占用相当于使用如下字符串的内存吗？|241017|241018|241019|不，它会引起更多的记忆混乱，而不仅仅是你引用的直连词。(直到/除非JVM优化器发现代码中的显式StringBuilder是不必要的，并在可能的情况下将其优化。)|241020|如果代码的作者想要使用StringBuilder+(有支持的论点，也有反对的论点；请参阅本答案末尾的注释)，最好正确地使用它(在这里，我假设id2和table周围实际上没有引号)：|241021|StringBuilder+sb+=+new+StringBuilder(some_appropriate_size);
sb.append("select+id1,+");
sb.append(id2);
sb.append("+from+");
sb.append(table);
return+sb.toString();|code-block|syntax|javascript|241022|注意，我已经在StringBuilder构造函数中列出了some_appropriate_size，所以它一开始就有足够的容量来容纳我们将要追加的全部内容。如果不指定，则使用的缺省大小是16+characters，它通常太小，导致StringBuilder不得不进行重新分配以使自己更大(在Sun/Oracle+JDK中，如果它知道每次耗尽空间时都需要更多的空间来满足特定的append，则它会将自己加倍或更多)。|241023|您可能听说过，如果使用Sun/Oracle编译器进行编译，字符串连接将在幕后使用StringBuilder。这是真的，它将使用一个StringBuilder作为整个表达式。但它将使用默认构造函数，这意味着在大多数情况下，它将不得不进行重新分配。不过，它更容易阅读。请注意，对于一系列连接，情况并非如此。例如，这使用了一个StringBuilder|241024|return+"prefix+"+%2B+variable1+%2B+"+middle+"+%2B+variable2+%2B+"+end";|241025|它大致翻译为：|241026|StringBuilder+tmp+=+new+StringBuilder();+//+Using+default+16+character+size
tmp.append("prefix+");
tmp.append(variable1);
tmp.append("+middle+");
tmp.append(variable2);
tmp.append("+end");
return+tmp.toString();|241027|所以这没问题，尽管默认构造函数和随后的重新分配并不理想，但很可能它已经足够好了-而且连接的可读性要好得多。|241028|但这仅适用于单个表达式。多个StringBuilder用于此操作：|241029|String+s;
s+=+"prefix+";
s+%2B=+variable1;
s+%2B=+"+middle+";
s+%2B=+variable2;
s+%2B=+"+end";
return+s;|241030|最终会变成这样：|241031|String+s;
StringBuilder+tmp;
s+=+"prefix+";
tmp+=+new+StringBuilder();
tmp.append(s);
tmp.append(variable1);
s+=+tmp.toString();
tmp+=+new+StringBuilder();
tmp.append(s);
tmp.append("+middle+");
s+=+tmp.toString();
tmp+=+new+StringBuilder();
tmp.append(s);
tmp.append(variable2);
s+=+tmp.toString();
tmp+=+new+StringBuilder();
tmp.append(s);
tmp.append("+end");
s+=+tmp.toString();
return+s;|241032|...which相当难看。|241033|但是，重要的是要记住，除了极少数情况外，在所有情况下都无关紧要，除非出现特定的性能问题，否则最好使用可读性(增强了可维护性)。|241034|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/6/docs/api/java/lang/StringBuilder.html#StringBuilder%2528%2529^0|0|0|0|0|G|D|17|3|1B|5|0|0|0|0|0|0|1B|D|0|B|D|1Y|3|22|5|0|0|7|D|S|L|37|D|57|6|2L|D|0|0|14|D|1T|D|4G|D|0|0|0|0|0|E|D|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|1X|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1Y|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1Z|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|20|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|21|7|@$H|22|I|23|J|K]|$H|24|I|25|J|K]|$H|26|I|27|J|K]]|8|@]|9|$]]|$1|L|3|M|4|5|6|28|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|29|7|@]|8|@]|9|$]]|$1|O|3|P|4|C|6|2A|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|2B|7|@]|8|@]|9|$]]|$1|R|3|-4|4|5|6|2C|7|@]|8|@]|9|$]]|$1|S|3|T|4|5|6|2D|7|@$H|2E|I|2F|J|K]]|8|@]|9|$]]|$1|U|3|V|4|5|6|2G|7|@$H|2H|I|2I|J|K]|$H|2J|I|2K|J|K]|$H|2L|I|2M|J|K]]|8|@]|9|$]]|$1|W|3|X|4|Y|6|2N|7|@]|8|@]|9|$Z|10]]|$1|11|3|12|4|5|6|2O|7|@$H|2P|I|2Q|J|K]|$H|2R|I|2S|J|K]|$H|2T|I|2U|J|K]|$H|2V|I|2W|J|K]]|8|@$H|2X|I|2Y|1|2Z]]|9|$]]|$1|13|3|14|4|5|6|30|7|@$H|31|I|32|J|K]|$H|33|I|34|J|K]|$H|35|I|36|J|K]]|8|@]|9|$]]|$1|15|3|16|4|Y|6|37|7|@]|8|@]|9|$Z|10]]|$1|17|3|18|4|5|6|38|7|@]|8|@]|9|$]]|$1|19|3|1A|4|Y|6|39|7|@]|8|@]|9|$Z|10]]|$1|1B|3|1C|4|5|6|3A|7|@]|8|@]|9|$]]|$1|1D|3|1E|4|5|6|3B|7|@$H|3C|I|3D|J|K]]|8|@]|9|$]]|$1|1F|3|1G|4|Y|6|3E|7|@]|8|@]|9|$Z|10]]|$1|1H|3|1I|4|5|6|3F|7|@]|8|@]|9|$]]|$1|1J|3|1K|4|Y|6|3G|7|@]|8|@]|9|$Z|10]]|$1|1L|3|1M|4|5|6|3H|7|@]|8|@]|9|$]]|$1|1N|3|1O|4|5|6|3I|7|@]|8|@]|9|$]]|$1|1P|3|-4|4|5|6|3J|7|@]|8|@]|9|$]]]|1Q|$1R|$4|1S|1T|1U|9|$1V|1W]]]]

<blockquote>
 The aim of using StringBuilder, i.e reducing memory. Is it achieved?
</blockquote>

No, not at all. That code is not using <code>StringBuilder</code> correctly. (I think you've misquoted it, though; surely there aren't quotes around <code>id2</code> and <code>table</code>?)

Note that the aim (usually) is to reduce memory churn rather than total memory used, to make life a bit easier on the garbage collector.

<blockquote>
 Will that take memory equal to using String like below?
</blockquote>

No, it'll cause more memory churn than just the straight concat you quoted. (Until/unless the JVM optimizer sees that the explicit <code>StringBuilder</code> in the code is unnecessary and optimizes it out, if it can.)

If the author of that code wants to use <code>StringBuilder</code> (there are arguments for, but also against; see note at the end of this answer), better to do it properly (here I'm assuming there aren't actually quotes around <code>id2</code> and <code>table</code>):

<pre><code>StringBuilder sb = new StringBuilder(some_appropriate_size);
sb.append("select id1, ");
sb.append(id2);
sb.append(" from ");
sb.append(table);
return sb.toString();
</code></pre>

Note that I've listed <code>some_appropriate_size</code> in the <code>StringBuilder</code> constructor, so that it starts out with enough capacity for the full content we're going to append. The default size used if you don't specify one is <a href="http://docs.oracle.com/javase/6/docs/api/java/lang/StringBuilder.html#StringBuilder%28%29">16 characters</a>, which is usually too small and results in the <code>StringBuilder</code> having to do reallocations to make itself bigger (IIRC, in the Sun/Oracle JDK, it doubles itself [or more, if it knows it needs more to satisfy a specific <code>append</code>] each time it runs out of room).

You may have heard that string concatenation will use a <code>StringBuilder</code> under the covers if compiled with the Sun/Oracle compiler. This is true, it will use one <code>StringBuilder</code> for the overall expression. But it will use the default constructor, which means in the majority of cases, it will have to do a reallocation. It's easier to read, though. Note that this is not true of a series of concatenations. So for instance, this uses one <code>StringBuilder</code>:

<pre><code>return "prefix " + variable1 + " middle " + variable2 + " end";
</code></pre>

It roughly translates to:

<pre><code>StringBuilder tmp = new StringBuilder(); // Using default 16 character size
tmp.append("prefix ");
tmp.append(variable1);
tmp.append(" middle ");
tmp.append(variable2);
tmp.append(" end");
return tmp.toString();
</code></pre>

So that's okay, although the default constructor and subsequent reallocation(s) isn't ideal, the odds are it's good enough&nbsp;&mdash; and the concatenation is a lot more readable.

But that's only for a single expression. Multiple <code>StringBuilder</code>s are used for this:

<pre><code>String s;
s = "prefix ";
s += variable1;
s += " middle ";
s += variable2;
s += " end";
return s;
</code></pre>

That ends up becoming something like this:

<pre><code>String s;
StringBuilder tmp;
s = "prefix ";
tmp = new StringBuilder();
tmp.append(s);
tmp.append(variable1);
s = tmp.toString();
tmp = new StringBuilder();
tmp.append(s);
tmp.append(" middle ");
s = tmp.toString();
tmp = new StringBuilder();
tmp.append(s);
tmp.append(variable2);
s = tmp.toString();
tmp = new StringBuilder();
tmp.append(s);
tmp.append(" end");
s = tmp.toString();
return s;
</code></pre>

...which is pretty ugly.

It's important to remember, though, that in all but a very few cases it doesn't matter and going with readability (which enhances maintainability) is preferred barring a specific performance issue.

blocks|key|244632|text|在您发布的代码中没有任何优势，因为您滥用了StringBuilder。在这两种情况下构建相同的字符串。使用StringBuilder，您可以避免使用append方法对字符串执行%2B操作。你应该这样使用它：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|244633|return+new+StringBuilder("select+id1,+").append("+id2+").append("+from+").append("+table").toString();|code-block|syntax|javascript|244634|在Java中，String类型是一个不可变的字符序列，因此当您添加两个String时，VM会创建一个连接了两个操作数的新字符串值。|244635|StringBuilder提供了一个可变的字符序列，您可以使用它来连接不同的值或变量，而无需创建新的字符串对象，因此它有时比使用字符串更有效|244636|这提供了一些有用的功能，比如更改在另一个方法中作为参数传递的char序列的内容，这是使用Strings所不能做到的。|244637|private+void+addWhereClause(StringBuilder+sql,+String+column,+String+value)+{
+++//WARNING:+only+as+an+example,+never+append+directly+a+value+to+a+SQL+String,+or+you'll+be+exposed+to+SQL+Injection
+++sql.append("+where+").append(column).append("+=+").append(value);
}|244638|欲了解更多信息，请访问http://docs.oracle.com/javase/tutorial/java/data/buffers.html|244639|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/tutorial/java/data/buffers.html^0|22|6|2G|1|0|0|0|0|0|0|B|1P|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|17|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|19|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1A|8|@]|D|@]|E|$]]|$1|Q|3|R|5|H|7|1B|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|1C|8|@]|D|@$9|1D|A|1E|1|1F]]|E|$]]|$1|U|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]]|V|$W|$5|X|Y|Z|E|$10|11]]]]

In the code you have posted there would be no advantages, as you are misusing the StringBuilder. You build the same String in both cases. Using StringBuilder you can avoid the <code>+</code> operation on Strings using the <code>append</code> method.
You should use it this way:

<pre><code>return new StringBuilder("select id1, ").append(" id2 ").append(" from ").append(" table").toString();
</code></pre>

In Java, the String type is an inmutable sequence of characters, so when you add two Strings the VM creates a new String value with both operands concatenated.

StringBuilder provides a mutable sequence of characters, which you can use to concat different values or variables without creating new String objects, and so it can sometimes be more efficient than working with strings

This provides some useful features, as changing the content of a char sequence passed as parameter inside another method, which you can't do with Strings.

<pre><code>private void addWhereClause(StringBuilder sql, String column, String value) {
 //WARNING: only as an example, never append directly a value to a SQL String, or you'll be exposed to SQL Injection
 sql.append(" where ").append(column).append(" = ").append(value);
}
</code></pre>

More info at <a href="http://docs.oracle.com/javase/tutorial/java/data/buffers.html" rel="nofollow">http://docs.oracle.com/javase/tutorial/java/data/buffers.html</a>

blocks|key|241106|text|当你已经拥有了你想要追加的所有“片段”时，使用StringBuilder就没有任何意义了。根据您的示例代码，在同一调用中使用StringBuilder和字符串连接甚至更糟糕。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|241107|这样会更好：|241108|return+"select+id1,+"+%2B+"+id2+"+%2B+"+from+"+%2B+"+table";|code-block|syntax|javascript|241109|在本例中，字符串连接实际上发生在编译时，因此它等同于更简单的：|BOLD|241110|return+"select+id1,+id2+from+table";|241111|在这种情况下，使用new+StringBuilder().append("select+id1,+").append("+id2+")....toString()实际上会影响性能，因为它强制在执行时执行连接，而不是在编译时执行连接。糟了。|241112|如果真正的代码是通过在查询中包含值来构建SQL查询，那么这是另一个单独的问题，即您应该使用参数化查询，在参数中指定值，而不是在SQL中指定值。|241113|在StringBuilder出现之前，我有一个article+on+String+/+StringBuffer是我写的。不过，这些原则也同样适用于StringBuilder。|241114|entityMap|0|LINK|mutability|MUTABLE|url|http://www.yoda.arachsys.com/java/strings.html^0|N|D|1Q|D|0|0|0|G|3|0|0|9|20|2O|3|30|2|0|0|1|D|Y|6|17|C|21|D|N|W|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1A|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|1B|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1C|8|@$9|1D|A|1E|B|O]]|D|@]|E|$]]|$1|P|3|Q|5|J|7|1F|8|@]|D|@]|E|$K|L]]|$1|R|3|S|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|O]|$9|1L|A|1M|B|O]]|D|@]|E|$]]|$1|T|3|U|5|6|7|1N|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|1O|8|@$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]|$9|1V|A|1W|B|C]]|D|@$9|1X|A|1Y|1|1Z]]|E|$]]|$1|X|3|-4|5|6|7|20|8|@]|D|@]|E|$]]]|Y|$Z|$5|10|11|12|E|$13|14]]]]

When you already have all the "pieces" you wish to append, there is no point in using <code>StringBuilder</code> at all. Using <code>StringBuilder</code> and string concatenation in the same call as per your sample code is even worse.

This would be better:

<pre><code>return "select id1, " + " id2 " + " from " + " table";
</code></pre>

In this case, the string concatenation is actually happening at compile-time anyway, so it's equivalent to the even-simpler:

<pre><code>return "select id1, id2 from table";
</code></pre>

Using <code>new StringBuilder().append("select id1, ").append(" id2 ")....toString()</code> will actually hinder performance in this case, because it forces the concatenation to be performed at execution time, instead of at compile time. Oops.

If the real code is building a SQL query by including values in the query, then that's another separate issue, which is that you should be using parameterized queries, specifying the values in the parameters rather than in the SQL.

I have an <a href="http://www.yoda.arachsys.com/java/strings.html" rel="noreferrer">article on <code>String</code> / <code>StringBuffer</code></a> which I wrote a while ago - before <code>StringBuilder</code> came along. The principles apply to <code>StringBuilder</code> in the same way though.

blocks|key|245983|text|您的猜测是正确的，使用字符串构建器的目的没有达到，至少没有达到它的全部范围。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|245984|但是，当编译器看到表达式"select+id1,+"+%2B+"+id2+"+%2B+"+from+"+%2B+"+table"时，它会发出在幕后实际创建StringBuilder并附加到它的代码，因此最终结果并不是那么糟糕。|offset|length|style|CODE|245985|但当然，任何看过这些代码的人都会认为它有点迟钝。|245986|entityMap^0|0|C|1A|1Z|D|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

You are correct in guessing that the aim of using string builder is not achieved, at least not to its full extent. 

However, when the compiler sees the expression <code>"select id1, " + " id2 " + " from " + " table"</code> it emits code which actually creates a <code>StringBuilder</code> behind the scenes and appends to it, so the end result is not that bad afterall.

But of course anyone looking at that code is bound to think that it is kind of retarded.

blocks|key|243543|text|您也可以使用MessageFormat|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|243544|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/1.4.2/docs/api/java/text/MessageFormat.html^0|6|D|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You could also use <a href="http://docs.oracle.com/javase/1.4.2/docs/api/java/text/MessageFormat.html" rel="nofollow">MessageFormat</a> too

blocks|key|3130227|text|[这里有一些很好的答案，但我发现他们仍然缺乏一点信息。]|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3130228|return+(new+StringBuilder("select+id1,+"+%2B+"+id2+"+%2B+"+from+"+%2B+"+table"))
+++++.toString();|code-block|syntax|javascript|3130229|因此，正如您所指出的，您给出的示例过于简单，但不管怎样，让我们分析它。因为"select+id1,+"+%2B+"+id2+"+%2B+"+from+"+%2B+"+table"都是常量，所以编译器实际上在这里做了%2B的工作。所以这就变成了：|offset|length|style|CODE|3130230|return+new+StringBuilder("select+id1,++id2++from++table").toString();|3130231|显然，在这种情况下，使用StringBuilder是没有意义的。你也可以这样做：|3130232|//+the+compiler+combines+these+constant+strings
return+"select+id1,+"+%2B+"+id2+"+%2B+"+from+"+%2B+"+table";|3130233|但是，即使您附加了任何字段或其他非常量，编译器也会使用内部StringBuilder+--您不需要定义它：|3130234|//+an+internal+StringBuilder+is+used+here
return+"select+id1,+"+%2B+fieldName+%2B+"+from+"+%2B+tableName;|3130235|在幕后，这变成了大致等同于：|3130236|StringBuilder+sb+=+new+StringBuilder("select+id1,+");
sb.append(fieldName).append("+from+").append(tableName);
return+sb.toString();|3130237|实际上，只有当你有条件代码时，你才需要直接使用StringBuilder。例如，如下所示的代码非常需要StringBuilder|3130238|//+1+StringBuilder+used+in+this+line
String+query+=+"select+id1,+"+%2B+fieldName+%2B+"+from+"+%2B+tableName;
if+(where+!=+null)+{
+++//+another+StringBuilder+used+here
+++query+%2B=+'+'+%2B+where;
}|3130239|第一行中的%2B使用一个StringBuilder实例。然后%2B=使用另一个StringBuilder实例。这样做效率更高：|3130240|//+choose+a+good+starting+size+to+lower+chances+of+reallocation
StringBuilder+sb+=+new+StringBuilder(64);
sb.append("select+id1,+").append(fieldName).append("+from+").append(tableName);
//+conditional+code
if+(where+!=+null)+{
+++sb.append('+').append(where);
}
return+sb.toString();|3130241|另一次我使用StringBuilder是当我从许多方法调用中构建一个字符串时。然后，我可以创建接受StringBuilder参数的方法：|3130242|private+void+addWhere(StringBuilder+sb)+{
+++if+(where+!=+null)+{
++++++sb.append('+').append(where);
+++}
}|3130243|当您使用StringBuilder时，您应该同时注意%2B的任何用法：|3130244|sb.append("select+"+%2B+fieldName);|3130245|该%2B将导致创建另一个内部StringBuilder。这当然应该是：|3130246|sb.append("select+").append(fieldName);|3130247|最后，正如@T.J.rowder所指出的，您应该始终猜测StringBuilder的大小。这将节省在增加内部缓冲区大小时创建的char[]对象的数量。|3130248|entityMap^0|0|0|11|1A|2T|1|0|0|C|D|0|0|T|D|0|0|0|0|N|D|1F|D|0|0|5|1|A|D|S|2|Z|D|0|0|6|D|1D|D|0|0|4|D|Q|1|0|0|1|1|C|D|0|0|S|D|1R|6|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1Q|8|@$I|1R|J|1S|K|L]|$I|1T|J|1U|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|1V|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1W|8|@$I|1X|J|1Y|K|L]]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1Z|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|20|8|@$I|21|J|22|K|L]]|9|@]|A|$]]|$1|U|3|V|5|D|7|23|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|24|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|25|8|@]|9|@]|A|$E|F]]|$1|10|3|11|5|6|7|26|8|@$I|27|J|28|K|L]|$I|29|J|2A|K|L]]|9|@]|A|$]]|$1|12|3|13|5|D|7|2B|8|@]|9|@]|A|$E|F]]|$1|14|3|15|5|6|7|2C|8|@$I|2D|J|2E|K|L]|$I|2F|J|2G|K|L]|$I|2H|J|2I|K|L]|$I|2J|J|2K|K|L]]|9|@]|A|$]]|$1|16|3|17|5|D|7|2L|8|@]|9|@]|A|$E|F]]|$1|18|3|19|5|6|7|2M|8|@$I|2N|J|2O|K|L]|$I|2P|J|2Q|K|L]]|9|@]|A|$]]|$1|1A|3|1B|5|D|7|2R|8|@]|9|@]|A|$E|F]]|$1|1C|3|1D|5|6|7|2S|8|@$I|2T|J|2U|K|L]|$I|2V|J|2W|K|L]]|9|@]|A|$]]|$1|1E|3|1F|5|D|7|2X|8|@]|9|@]|A|$E|F]]|$1|1G|3|1H|5|6|7|2Y|8|@$I|2Z|J|30|K|L]|$I|31|J|32|K|L]]|9|@]|A|$]]|$1|1I|3|1J|5|D|7|33|8|@]|9|@]|A|$E|F]]|$1|1K|3|1L|5|6|7|34|8|@$I|35|J|36|K|L]|$I|37|J|38|K|L]]|9|@]|A|$]]|$1|1M|3|-4|5|6|7|39|8|@]|9|@]|A|$]]]|1N|$]]

[[ There are some good answers here but I find that they still are lacking a bit of information. ]]

<pre><code>return (new StringBuilder("select id1, " + " id2 " + " from " + " table"))
 .toString();
</code></pre>

So as you point out, the example you give is a simplistic but let's analyze it anyway. What happens here is the compiler actually does the <code>+</code> work here because <code>"select id1, " + " id2 " + " from " + " table"</code> are all constants. So this turns into:

<pre><code>return new StringBuilder("select id1, id2 from table").toString();
</code></pre>

In this case, obviously, there is no point in using <code>StringBuilder</code>. You might as well do:

<pre><code>// the compiler combines these constant strings
return "select id1, " + " id2 " + " from " + " table";
</code></pre>

However, even if you were appending any fields or other non-constants then the compiler would use an internal <code>StringBuilder</code> -- there's no need for you to define one:

<pre><code>// an internal StringBuilder is used here
return "select id1, " + fieldName + " from " + tableName;
</code></pre>

Under the covers, this turns into code that is approximately equivalent to:

<pre><code>StringBuilder sb = new StringBuilder("select id1, ");
sb.append(fieldName).append(" from ").append(tableName);
return sb.toString();
</code></pre>

Really the only time you need to use <code>StringBuilder</code> directly is when you have conditional code. For example, code that looks like the following is desperate for a <code>StringBuilder</code>:

<pre><code>// 1 StringBuilder used in this line
String query = "select id1, " + fieldName + " from " + tableName;
if (where != null) {
 // another StringBuilder used here
 query += ' ' + where;
}
</code></pre>

The <code>+</code> in the first line uses one <code>StringBuilder</code> instance. Then the <code>+=</code> uses another <code>StringBuilder</code> instance. It is more efficient to do:

<pre><code>// choose a good starting size to lower chances of reallocation
StringBuilder sb = new StringBuilder(64);
sb.append("select id1, ").append(fieldName).append(" from ").append(tableName);
// conditional code
if (where != null) {
 sb.append(' ').append(where);
}
return sb.toString();
</code></pre>

Another time that I use a <code>StringBuilder</code> is when I'm building a string from a number of method calls. Then I can create methods that take a <code>StringBuilder</code> argument:

<pre><code>private void addWhere(StringBuilder sb) {
 if (where != null) {
 sb.append(' ').append(where);
 }
}
</code></pre>

When you are using a <code>StringBuilder</code>, you should watch for any usage of <code>+</code> at the same time:

<pre><code>sb.append("select " + fieldName);
</code></pre>

That <code>+</code> will cause another internal <code>StringBuilder</code> to be created. This should of course be:

<pre><code>sb.append("select ").append(fieldName);
</code></pre>

Lastly, as @T.J.rowder points out, you should always make a guess at the size of the <code>StringBuilder</code>. This will save on the number of <code>char[]</code> objects created when growing the size of the internal buffer.

I just found some sql query build like this in my project:

<pre><code>return (new StringBuilder("select id1, " + " id2 " + " from " + " table")).toString();
</code></pre>

Does this <code>StringBuilder</code> achieve its aim, i.e reducing memory usage?

I doubt that, because in the constructor the '+' (String concat operator) is used. Will that take the same amount of memory as using String like the code below? s I understood, it differs when using <code>StringBuilder.append()</code>.

<pre><code>return "select id1, " + " id2 " + " from " + " table";
</code></pre>

Are both statements equal in memory usage or not? Please clarify. 

Thanks in advance!

Edit:

BTW, it is not my code. Found it in an old project. Also, the query is not so small as the one in my example. :)

Correct way to use StringBuilder in SQL

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我刚刚在我的项目中找到了一些sql查询构建：return (new StringBuilder("select id1, " + " id2 " + " from " + " table")).toString();这个StringBuilder是否达到了它的目标，即减少内存使用？我对此表示怀疑，因为在构造函数中使用了...

问在SQL中正确使用StringBuilder
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在SQL中正确使用StringBuilderEN