1. 两个线程只有处理 公共变量的时候，才有线程安全和不安全的问题，如果两个线程执行完之后，公共变量的值是不确定的，那么就是线程不安全的；
2. 两个线程，如果对相同的变量的操作部分代码，都加同一个锁，那么肯定是线程安全的，加锁，其实是将锁定的代码块变成了一个原子性的，但是性能可能不高，一般说的锁是一种悲观锁，为了增加性能会有各种改进的锁：读写锁，cmpandset
3. 如果不加锁，哪些情况会造成是线程不安全呢，或者造成公共变量最终结果不确定呢？
对公共变量的操作，有很多步，有时候看起来是一行代码，其实里面包含多个cpu指令，
没加原子限定的代码，原子单位是cpu指令
可见性：主内存和工作内存(缓存)，在线程里操作主存的变量，会经过多个指令，线程对一个工作内存修改之后，这个修改不会原子地刷到主存，而是由cpu控制，不确定多长时间，才刷到主存，但是一般延迟比较小；典型的两个线程对一个整数++操作，就可能出错；volatile可以解决这个问题，线程的修改可以原子地刷到主存；
指令重排：同一个线程内部的，相互独立的代码对应的指令的顺序，可能会重排，也就是顺序调换，一个场景：在一个线程内关闭一个资源，然后置标志位为关闭，另一个线程根据标志位来判断是不是要关闭资源，这时候就可能出现关闭已经关闭的资源的问题；volatile可以防止指令重排，有volatile修饰的变量，前后的指令不会调换，但是volatile前面或者后面的所有指令可能会重排；
4. concurrenthashmap：
普通的hashmap会有哪些线程不安全的问题呢？ 这里讨论的是添加或删除键值对，或者键值对超过一定数量，map要扩容时，存在线程不安全的问题
http://blog.csdn.net/mydreamongo/article/details/8960667
Map m = Collections.synchronizedMap(new HashMap(...)); 可以这样来将一个hashmap整个包成同步的
也可以使用concurrenthashmap，这里面按照hash分成16份，每份加一个锁，外面调用完全不用加锁；
但是无论是concurrenthashmap还是hashmap，都不保证对于value的修改的线程安全，这时候value可以考虑用原子类型！比如AtomicInteger等，
如果value是一个对象呢？
包装为一个原子的类型 AtomicReference<T>
或者将value里的数值类型value，可以定义为Atomic
5. atomic类型：无锁类，由cpu保证原子性；
6. cmpandset：乐观锁，认为发生修改的概率不大，所以不用每次都加锁，只需要判断一下是否发生改变就修改，CAS整一个操作过程是一个原子操作，它是由一条CPU指令完成的。
7. 读写锁：从一个读写锁会衍生出读锁和写锁，两个线程可以同时拥有读锁，但是只要有一个线程 有写锁，或者正在请求写锁，那么别人就请求不到读锁，同时如果有一个线程有读锁，需要读锁释放之后，别的线程才能请求到写锁；可重入读写锁，是可以降级的，有写锁之后，可以继续请求读锁，然后把写锁释放，这样就变成一个读锁了，但是有读锁是不可以重入到写锁的；
8. 可重入锁：一个线程用了一个锁之后，可以再次获取这个锁，这样只有这个线程两次释放这个锁，才算真正释放了
9. threadlocal<T>：用threadlocal修饰的公共变量，其实会变成每个线程独立维护的副本，一个线程对它的修改不会影响别的先用成这个threadlocal，它的原理是threadlocal类内部，有一个字典，key是线程名，value是对应的个T对象；
10. 共享锁和排它锁：一般的lock是排它锁，也就是同时只能有一个现成锁定，像读写锁和countletchdown是共享锁；