锁优化策略：标志位修改等可见性场景优先使用volatile

一旦开启了多线程，多线程访问一些共享的变量或者数据，所以在写这种并发的代码时候，要考虑清楚这个变量并发访问的场景，是并发读还是并发写?
如果仅仅只是有一些线程会来写一个变量，标志位，另外一个线程是来读取这个标志位的值，那么此时优先使用volatile。
能不用锁尽量别用锁，就会比较麻烦，可能会导致锁争用和冲突，如果没弄好的，锁的问题，可能会导致系统的吞吐量、性能会大幅度的降低。
案例回顾：Thread源码剖析之inturrept实战

锁优化策略：数值递增场景优先使用Atomic原子类

如果变量不再是有的人写有的人读。而是大家一块并发的写，同时是仅仅简单的数值累加或者变更数值的操作。就需要用Atomic原子类，cas无锁化机制，要比synchronzied要好
案例回顾：atomic相关实战

锁优化策略：数据允许多副本场景优先使用ThreadLocal

如果不需要多个线程共享读写一个数据的话，可以让每个线程保持一个本地变量的副本的话，那么可以搞一个ThreadLocal，让每个线程都维护一个变量的副本，每个线程就操作自己本地的副本就可以了。
案例回顾：editlog 实现自增的全局id

锁优化策略：读多写少需要加锁的场景优先使用读写锁

volatile、Atomic、ThreadLocal，都不适用的情况下，还要保证并发安全和性能，就可以用读写锁来解决这个问题
读多写少的场景，读写锁分离，读锁 -> 大量的线程并发的读，写锁 -> 写数据其他人不能写同时来写，也不能有人来读
案例回顾：读写锁优化服务注册表的加锁读写

锁优化策略：尽可能减少线程对锁占用的时间

读写锁用不了，只能用synchronized锁。那么就得保证单一加锁时间不能太长。不要在锁代码块中执行一些磁盘文件读写、网络IO读写，导致锁占用的时间过于长。
一般来说，加锁，尽量就是操作一下内存里的数据就可以了，不要在锁里面去执行一些耗时的一些操作，比如说执行数据库操作，SQL，或者是别的一些东西，可能会导致占用锁的时间很长。
案例回顾：Edit log分段加锁

锁优化策略：尽可能减少线程对数据加锁的粒度

比方说，你手上有一份数据，里面包含了多个子数据，你加锁，可以对一整块完整的大数据来加锁，别人只要访问这一大块数据，都会有锁的争用的问题。你也可以选择降低加锁的粒度，你仅仅对大块数据里的部分子数据加锁

锁优化策略：尽量减少高并发场景中线程对锁的争用

读写锁主要是解决了大量的读请求不会串行化，读请求可以并发起来。
写锁和读锁，还是会冲突问题，如果有服务实例注册、下线，这时候加写锁，此时还是会短暂的影响别的线程来都读注册表的数据。加读锁是加不上的。
降低锁竞争的频率。
案例回顾：注册表改造成多级缓存。