• Post Reply Bookmark Topic Watch Topic
  • New Topic

StringBuffer is useless ?  RSS feed

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was going through the article on the below link which says the string buffer is useless. Is the string buffer synchronization a useless stuff ?

http://jeremymanson.blogspot.com/2008/08/dont-use-stringbuffer.html
 
Marshal
Posts: 56605
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are rather exaggerating what that blog says, but it explains how using a StringBuffer in two threads can result in unpredictable behaviour. But that is a rather contrived situation designed to produce unpredictable results.
That is why many people nowadays hardly use StringBuffer.
The StringBuffer API documentation is reasonably clear about it.
 
Kalyan Anand
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ok thankyou
 
Campbell Ritchie
Marshal
Posts: 56605
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome
 
Kalyan Anand
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suddenly get a new thought here. So assumed that making the string buffer synchronized was of no use which they realized in java 1.5 and going by same idiom we have vector.

Here is the text from Java Concurrency in Practise

If synchronization is the cure for race conditions, why not just declare every method synchronized? It turns out that such indiscriminate application of synchronized might be either too much or too little synchronization. Merely synchronizing every method, as Vector does, is not enough to render compound actions on a Vector atomic:

if (!vector.contains(element))
vector.add(element);



This attempt at a put-if-absent operation has a race condition, even though both contains and add are atomic. While synchronized methods can make individual operations atomic, additional locking is requiredwhen multiple operations are combined into a compound action. (See Section 4.4 for some techniques for safely adding additional atomic operations to thread-safe objects.) At the same time, synchronizing every method can lead to liveness or performance problems, as we saw in SynchronizedFactorizer.


Now does that mean anything under Collections framework was inadequately designed ?

A true question that struck me and I am not pin pointing something
 
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the design of Java 1.0 with StringBuffer and Vector, the designers were very cautious. Subsequent evolution led to additional solutions but the original classes are still there to provide continuity.

Bill
 
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Bill]: In the design of Java 1.0 with StringBuffer and Vector, the designers were very cautious.

Hm, I think that's being overly generous. Despite being "cautious" they designed APIs that are not, generally, safe to use with multiple threads (without additional synchronization) yet described them as "thread-safe". A dangerously misleading idea, I think.

[Santhosh]: Now does that mean anything under Collections framework was inadequately designed ?

Well, the objects returned by Collections.synchronizedList() and other synchronizedXXX() methods are just as flawed as Vector is. They do document that the Iterator requires external synchronization in order to be safe, which is an improvement over the original Vector. But they fail to make the same point about any other set of compound actions you might want to perform on a mutable collection. And they continue to use the term "thread-safe" to mislead young programmers into thinking that they're, well, safe in using multiple threads with this class.

[Campbell]: But that is a rather contrived situation designed to produce unpredictable results.

Mmmm, I think it's not contrived at all. Unpredictable behavior is pretty easy to find if you're accessing a StringBuffer from multiple threads without external synchronizaztion. I'd have to work harder to imagine a realistic scenario where it's not an issue. Maybe if no threads ever remove any characters, or if only one thread removes (and other operations) while all the other threads can only append new data. But in any situation where one thread may remove one or more characters while another thread tries to read them, you need some sort of external synchronization to handle the situation safely. That, or you need to be willing to catch some sort of IndexOutOfBoundsException to handle what happens when data is deleted just as you try to read it. Ugh.

In short, while I can't say that the synchronization in StringBuffer and Vector is completely useless, I think it's pretty darned close to useless. And more importantly, it's dangerously misleading to other programmers, who usually need more synchronization in order to be safe. Which is worse than useless, in my mind. I say, do not trust any class that's labeled as "thread-safe" - Sun has badly misused this term over the years. Though I do approve of later classes like ConcurrentHashMap, which provide more useful methods, and document their limitations better.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!