StringBuffer and StringBuilder have the same function, but StringBuilder is newer and should be preferred. The difference between the two is that most of the methods of StringBuffer are synchronized, while the methods of StringBuilder are not. Synchronization is only needed when you use the same object in multiple threads at the same time, which you don't do most of the time. Since synchronization adds some runtime overhead, doing it all the time is a waste, so the Sun people added StringBuilder without the unnecessary synchronization. (This is similar to the difference between Vector and ArrayList).
A String is a String. No problem with that, right ? A minor concern with Strings is that they are immutable. When you append another String to it, a new String is being instantiated. For example:
Here, you could think that the "a" instance is the same after the concatenation, but no. Strings are immutable, so the "a" instance will not change. When we append something to it, a new instance will be created and assigned to "a" again. This is time consuming (very slightly...). To prevent that, StringBuffer came to the rescue. You can append Strings and do other String operations without having new instantiation all over. StringBuffer is thread-safe though, which means that it has some special protection to be multi thread friendly. This may also be a bit time consuming (slightly...) So then came StringBuilder, a not thread-safe StringBuffer. Doing the same stuff, but not thread-safe. Who cares if you're single threaded ?
Note also that if you use + (or +=) with String objects, the compiler does some magic - it generates code that uses a StringBuilder behind the scenes to concatenate strings. Have a look at this example:
Compile it and then disassemble it with the command: javap -c Example and you'll see this:
Translating this back to regular Java, you see that it looks something like this: