• Post Reply Bookmark Topic Watch Topic
  • New Topic

Difference between Stringbuilder and Stringbuffer class  RSS feed

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello everyone,
upto theory i come to know stringbuffer is a synchronized class (i.e thread safe ) while Stringbuilder is not.
even all the function applied on both the class are same
let me know about the best example through which we can differentiate both the class
please help
 
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Write a class that creates a number of threads that all manipulate the same StringBuffer instance concurrently.
 
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sparsh khandelwal wrote: . . . stringbuffer is a synchronized class (i.e thread safe ) . . .
Are we sure StringBuffer is thread‑safe?
I usually use such objects as local variables, where threading issues do not apply.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
sparsh khandelwal wrote: . . . stringbuffer is a synchronized class (i.e thread safe ) . . .
Are we sure StringBuffer is thread‑safe?


Indeed. There's no such thing as a "synchronized class," but if we take it to mean "a class, all of whose non-private methods are synchronized," then, okay, fine, we can call it that.

The real issue though is that making every method synchronized does not make the class "thread-safe," at least not in the sense that I think a lot of people assume it does. It's trivially easy to use such a class in a thread-unsafe way. For instance, with StringBuffer, if I call sb.append("a").append("b") in 2 threads simultaenously, I could end up appending "aabb" or "abab".


I usually use such objects as local variables, where threading issues do not apply.


Me too. I never really understood the point of StringBuilder. By the time it came out, unconstested synchronization had become quite fast, and you wouldn't use it in a case where the synchronization could be contested, so where's the benefit?. And I don't think I've ever in 15 years of Java programming used a StringBuffer/Builder in a situation where thread safety was an issue anyway, so, again, it seems like there's really no point in it. Granted, it was a trivially easy class to create, but still.
 
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:Me too. I never really understood the point of StringBuilder ... And I don't think I've ever in 15 years of Java programming used a StringBuffer/Builder in a situation where thread safety was an issue anyway, so, again, it seems like there's really no point in it.

Don't you mean the opposite - what's the point of StringBuffer? StringBuilder is what StringBuffer should have been; it's StringBuffer without the synchronization that nobody needs. There was no point in synchronizing StringBuffer, because nobody uses it from multiple threads concurrently. Unfortunately StringBuffer isn't going to be removed because of backward compatibility reasons, even worse, it's not even going to become deprecated, because Oracle is afraid that it would annoy too many people who have been using StringBuffer all the time in their source code with deprecation warnings.

Anyway, the point is: Forget about StringBuffer. Always use StringBuilder instead.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:
Jeff Verdegan wrote:Me too. I never really understood the point of StringBuilder ... And I don't think I've ever in 15 years of Java programming used a StringBuffer/Builder in a situation where thread safety was an issue anyway, so, again, it seems like there's really no point in it.

Don't you mean the opposite - what's the point of StringBuffer? StringBuilder is what StringBuffer should have been;


No, I meant what's the point in StringBuilder.

True, the syncing in Buffer was pointless. But it also was harmless, at least by the time Builder came along. So once all that code is out there using Buffer, why bring in Builder to address a tiny design flaw that has no real consequences?

Anyway, the point is: Forget about StringBuffer. Always use StringBuilder instead.


Yeah, now that it's there, we might as well use it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!