As you know StringBuffer is synchronized so only one time one thread can access StringBuffer object. SO when you are accessing StringBuffer object no one can change and use this object. So second thread not modify the object of StringBuffer and that is why it's tread safe.
Thus, when a single thread is to be used to run the application it is better to use StringBuilder and if the application is to be accessed from multiple threads, StringBuffer should be used because of its synchronized feature.
A thread safe class ensures that the class's internal state is accessed safely by multiple threads. However using a thread safe class need not necessarily mean that your program is acting in a thread safe way. It simply means that the object in question will execute operations in a thread safe manner
You could argue that it was a design mistake to make the StringBuffer class synchronized. It's synchronized to make it thread-safe, which means that if there are multiple threads that try to append data to the same StringBuffer object, you're sure that it doesn't get into an inconsistent state.
In practice, programs almost never use one StringBuffer object in multiple threads at the same time, so for most programs the synchronization is not necessary and only adds overhead.
That's why in Java 1.5 Sun added StringBuilder - the same thing as StringBuffer, but without the synchronization overhead that's unnecessary for most programs.
You should prefer to use StringBuilder, and only use StringBuffer if you really are using the object from multiple threads at the same time. And even then you could use StringBuilder and do the synchronization yourself.
StringBuffer was not removed from the Java API because there are lots of old programs that use it and Java must remain backward compatible.