Using StringBuffer without synchronized

[Rajagopal Mani]

Hi Everyone,

This topic is being discussed multi time in this forum. However, I need to confirm the below piece of code against concurrency.

public static String getXXXId(Message msg) {
        
        String id = null;
        
        if(null != msg){
                        
            id= new StringBuffer(msg.id1).append(msg.id2).toString();
        }
        
        return id;
    }

The above utility function is being used in multi thread environment. I dont declare this static method as synchronized one. I beleive that using StringBuffer enough to protect against concurrency issue. Can you please correct if am wrong.

-Raj

[Matthew Brown]

You only need the StringBuffer or StringBuilder synchronized if you have more than one thread accessing the same one. But here it's a local variable, so there's no need for it.

If there's any threading issues with that code it's in the Message objects, which may or may not be shared (it depends on how the method is called). And the StringBuffer doesn't have any effect there.

[Rajagopal Mani]

If there's any threading issues with that code it's in the Message objects, which may or may not be shared (it depends on how the method is called). And the StringBuffer doesn't have any effect there.

The "Message" which is passed is just a bean object. There are diff "Message" instances would be passed to this utility function from so many areas(eq. Services, Class run by threads). My doubt here is if any service invokes this method during another works on it, is it any possible to return improper id due to concurrency? Here, synchronized can be used to avoid concurrency issue. But, feel like synchronized may be overloaded in this case if no possibility of concurrency issue @ any time. Please provide your valuable suggestions :-)

-Raj

[Jesper de Jong]

If another thread has a reference to the Message object then it could modify the Message object (if it's not immutable) while your getXXXId method is reading fields from it.

But making the getXXXId method synchronized, or doing something with synchronizing the StringBuffer object, is not going to help you at all with regard to this. If you make the getXXXId method synchronized, it just means that two threads who call this method won't run it on the same time. But there still could be code somewhere else in a different thread that modifies the Message object.

You should prefer StringBuilder instead of StringBuffer, because StringBuilder doesn't contain the unnecessary synchronization that StringBuffer contains.

[Matthew Brown]

Rajagopal Mani wrote:My doubt here is if any service invokes this method during another works on it, is it any possible to return improper id due to concurrency?

Each method call has its own copy of local variables, so they can't interfere with each other. The only possible issue is the Jesper mentions, and synchronization in this method can't prevent that by itself.

[Rajagopal Mani]

Thanks for your valuable replies & making understanding. Any more better link to refer in this regard would help to understand in detail.

-Raj