当一个类的方法或静态方法被并发使用的时候，很可能会造成线程安全隐患。如果你没有在一个类的文档中描述其行为的并发性情况，使用这个类的其他人将不得不做出某些demo来验证它是否并发安全，可能缺少足够的同步，或者过度同步，无论属于这其中的哪种情况，都可能会发生严重的错误。我们可能听过这样的说法：通过查看文档中是否出现synchronized修饰符，可以确定一个方法是否是线程安全的。这种说法是错误的，在正常的操作中,Javadoc并没有在它的输出中包含synchronized修饰符，因为在一个方法声明中出现synchronized修饰符，这是个实现细节，并不是导出的API的一部分。它并不一定表明这个方法是线程安全的。
“出现了synchronized关键字就足以用文档说明线程安全性”的这种说法隐含了一个错误的观念，即认为线程安全性是一种“要么全有要么全无”的属性。实际上，线程安全性有多种级别。一个类为了可被多个线程安全的使用，必须在文档中清楚地说明他所支持的线程安全性级别。
不可变的（immutable）——这个类的实例是不变的。所以，不需要外部的同步。这样的例子包括String、Long和BigInteger。
无条件的线程安全（unconditionally thread-safe）——这个类的实例是可变的，但是这个类有足够的内部同步，所以，它的实例可以被并发使用，无需任何外部同步。其例子包括Random和ConcurrentHashMap。
有条件的线程安全（conditionally thread-safe）——除了有些方法为进行安全的并发使用而需要外部同步之外，这种线程安全级别与无条件的线程安全相同。这样的例子包括Collections.synchronized包装返回的集合，他们的迭代器要求外部同步。
非线程安全（not thread-safe）——这个类的实例是可变的。为了并发的使用他们，客户必须利用自己选择的外部同步包围每个方法调用（或者调用序列）。这样的例子包括通用的集合实现，例如ArrayList和HashMap。
线程对立的（thread-hostile）——这个类不能安全的被多个线程并发使用，即使所有方法调用都被外部同步包围。线程对立的根源通常在于，没有同步的修改静态数据。没有人会有意编写一个线程对立的类；这种类是因为没有考虑到并发性而产生的后果。幸运的是，在Java平台类库中，线程对立的类或方法非常少。System.runFinalizersOnExit方法是线程对立的，但已经被废除了。最后一条基本可以忽略不计。
每个类都应该利用字斟句酌的说明或者线程安全注解，清楚地在文档中说明他的线程安全属性。sychronized修饰符与这个文档毫无关系。有条件的线程安全类必须在文档中指明“哪个方法调用序列需要外部同步，以及在执行这些序列的时候要获得哪把锁”。如果你编写的是无条件的线程安全类，就应该考虑使用私有锁对象来代替同步的方法。这样可以防止客户端程序和子类的不同步干扰，让你能够在后续的版本中灵活的对并发控制采用更加复杂的方法。
这一条我也理解不是很到位。总之，在并发情况下，如果想让东西初始化一次，要么把它写成单利，要么对方法加锁，或者可以用 String 或 BigInteger ，如果初始化过一次，就赋一个值，或者让本身加1，判断它的值是否初始化，我们最终还是要善用方法，完成功能。