> Lock safe methodologies can prevent the crash, and if designed specifically for the data in question and the data structure supports it, can possibly ensure

> Lock safe methodologies can prevent the crash, and if designed specifically for the data in question and the data structure supports it, can possibly ensure no corruption. Which was the entire point of my post. "Thread-safe" does not guarantee "usage-safe", and using them interchangeably is a fallacy. If the synchronized StringBuffer does not provide the guarantees you need anyway, there's no point in paying the cost of using it. > Given with strings you probably have data corruption no matter what, do you want crashes on top of that or not? I just said that, yes, I would rather the program crash than silently corrupt data. I would rather it crash 100% of the time, but I'll take intermittent crashes instead. A crashed process can be restarted; it's very much harder to fix data once corruption hits. And if data corruption hits anyway, at least if I also have a crash I have an idea of where to look for the issue.