1

String objects are immutable so it is inherently thread safe, so I can use it without synchronization in thread context.

StringBuffer objects have the methods synchronized, so if threads are trying to execute its methods will not have a problem without synchronization.

But using its object as a resource in threads context requires it to have synchronization.

I am not able to understand the highlighted part clearly. Could anyone please explain or give a reference with code so that it clears my doubt.

Roman C
  • 49,761
  • 33
  • 66
  • 176
Rajesh
  • 213
  • 4
  • 15

3 Answers3

2

From the javadocs:

Whenever an operation occurs involving a source sequence (such as appending or inserting from a source sequence) this class synchronizes only on the string buffer performing the operation, not on the source.

Which means that if you have, for example, the code like:

StringBuffer bufferOne = new StringBuffer("abc");
StringBuffer bufferTwo = new StringBuffer("def");

bufferOne.append(bufferTwo);

Then it is synchronized only on bufferOne, but not bufferTwo. In another words, some other threads may read or write bufferTwo while this operation is being executed.

Scadge
  • 9,380
  • 3
  • 30
  • 39
1

String is immutable ( once created can not be changed )object . The object created as a String is stored in the Constant String Pool . Every immutable object in Java is thread safe ,that implies String is also thread safe . String can not be used by two threads simultaneously. String once assigned can not be changed .

String  demo = " hello " ;

// The above object is stored in constant string pool and its value can not be modified.

demo="Bye" ; 

//new "Bye" string is created in constant pool and referenced by the demo variable
// "hello" string still exists in string constant pool and its value is not overrided but we lost reference to the "hello"string

StringBuffer is mutable means one can change the value of the object . The object created through StringBuffer is stored in the heap . StringBuffer has the same methods as the StringBuilder , but each method in StringBuffer is synchronized that is StringBuffer is thread safe .

Due to this it does not allow two threads to simultaneously access the same method . Each method can be accessed by one thread at a time .

But being thread safe has disadvantages too as the performance of the StringBuffer hits due to thread safe property . Thus StringBuilder is faster than the StringBuffer when calling the same methods of each class.

 StringBuffer value can be changed , it means it can be assigned to the new value 

String Buffer can be converted to the string by using toString() method.

StringBuffer demo1 = new StringBuffer("Hello") ;

// The above object stored in heap and its value can be changed .

demo1=new StringBuffer("Bye");

// Above statement is right as it modifies the value which is allowed in the StringBuffer

 StringBuilder  is same as the StringBuffer , that is it stores the object in heap and it can also be modified . The main difference between the StringBuffer and StringBuilder is that StringBuilder is also not thread safe. 

StringBuilder is fast as it is not thread safe .

StringBuilder demo2= new StringBuilder("Hello");

// The above object too is stored in the heap and its value can be modified

demo2=new StringBuilder("Bye"); 
Hari
  • 11
  • 2
0

If you take a look at the javadoc it states the following:

Whenever an operation occurs involving a source sequence (such as appending or inserting from a source sequence) this class synchronizes only on the string buffer performing the operation, not on the source.

This means that if several threads has access to the source it is possible that another thread modifies the source before it is written.

A simple example, that might make this a bit clearer.

StrginBuffer sb = new StringBuffer
//some other thread might change the sharedSource.
sb.append(getSharedString());
Daniel Figueroa
  • 10,348
  • 5
  • 44
  • 66
  • 3
    Since you have not defined sharedSource as final, it is possible that you could assign it to a different value. The content of sharedSource CANNOT change. Strings are immutable. No activity on a separate thread could have any impact. – Brett Okken Jun 07 '14 at 13:09
  • D'oh, bad example, I've updated. Thanks @BrettOkken! – Daniel Figueroa Jun 07 '14 at 13:13
  • Perhaps a better example would be working with a CharSequence or another StringBuffer as both are mutable. – Brett Okken Jun 07 '14 at 13:25
  • I'd think this example is valid enough, since the reference might change in any case, causing a read which might not be what the user expects. Plus this question has receieved a lot of attention with one answer doing exactly as you suggest so no point in reiterating that. – Daniel Figueroa Jun 07 '14 at 13:31