Eric Sosman <esosman@comcast-dot-net.invalid> writes:
On 1/10/2013 6:37 AM, Jukka Lahtinen wrote:
Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
On 1/9/13 2:51 PM, Lew wrote:
'StringBuffer' is no more thread safe than any other class with
synchronized methods.
Which is more safe than other classes without synchronized methods.
They are thread-safe to the point that each method call is atomic. What
else could you ask for? They didn't lie.
Whenever thread safety is needed, you mostly need to synchronize not
only the single method call to an instance of StringBuffer or some other
class of the jdk, but also some context around it.
This is probably not the case, because another thread might
call an (unsynchronized) StringBuilder method while you're in
the middle of your synchronized block:
If you use the same instance in many places, potentially in different
threads, you should of course synchronize all of them using the same
lock.
StringBuilder sb = ...;
// Thread T1:
synchronized(sb) {
if (sb.charAt(sb.length() - 1) == '\n') {
sb.deleteCharAt(sb.length() - 1);
}
}
This is an example of what I wrote above. You need that synchronization
to prevent others from modifying sb between the charAt, length and
deletCharAt calls anyway.
Using StringBuffer instead of StringBuilder does NOT accomplish that.
// Thread T2:
sb.append("Gotcha!");
And so, this should be
synchronized(sb) {
sb.append("Gotcha?");
}
The synchronization in T1's code is no protection against
interference from T2. If `sb' were changed from a StringBuilder
to a StringBuffer, the race condition would disappear.
Neither is using StringBuffer.
Like I said, you could be in trouble if T2 makes that call somewhere
between the calls to the first sb.length() and sb.deletCharAt in T1 even
if sb is a StringBuffer.
longer). No race, no trouble.