Your name code is a perfect example. You can make the fullName method atomic, but that won’t help when someone needs a fullNameWithLastNameFirst method, or any of a zillion other variations.

I’ve been writing multithreaded code in Java for over a decade, and I firmly believe that 99% of the time accessors should not be thread safe. It just gives a misplaced sense of security.

For the Dude class, I’d make it explicitly thread unsafe, so that people using it won’t be tempted to use the same Dude in multiple threads. If you need to access it from multiple threads, you make copies of it. If that’s too inefficient for you, then you make its fields read-only.

They say that multithreaded programming is hard. That’s half true. It’s nigh impossible to debug when things go wrong. (Especially when the processor is allowed to execute code out-of-order in each thread.) But the trick to writing multithreaded programs is not to do anything clever. Simple, blunt rules (e.g. copy, don’t share) get the job done every time. And, thanks to the machine second-guessing you, they usually turn out to be more efficient than cleverness anyway.