并发编程10-性能和可伸缩性

性能的思考

使用多线程也会引入一些性能的开销，比如线程协调，上下文切换，线程创建和消亡。 当使用过度的时候这些开销可能超过对吞吐量响应和提高计算能力带来的好处。
可伸缩性就是可以通过增加计算资源(CPU，内存)来提供程序的吞吐量或者性能。
程序的串行化代码影响程序的性能，使用多线程来优化性能时，串行部分无法优化。
上下文切换，比如哪个等待，哪个执行，会损害性能
竞争性的锁会损失性能和可伸缩性。

减少锁的竞争

通常可以：
- 减少持有锁的时间
- 减少请求锁的频率
- 用协调机制代替独占锁

缩小锁的范围

快进快出原则，为了减少持有锁的时间

分拆锁

private List<String> list1 = new ArrayList<String>();
    private List<String> list2 = new ArrayList<String>();

    public synchronized void add1(String item){
        list1.add(item);
    }

    public synchronized void add2(String item){
        list2.add(item);
    }

分拆为：

private List<String> list1 = new ArrayList<String>();
    private List<String> list2 = new ArrayList<String>();

    public void add1(String item){
        synchronized(list1){
            list1.add(item);
        }

    }

    public void add2(String item){
        synchronized(list2){
            list2.add(item);
        }
    }

分离锁

跟分拆锁差不多。不如ConcurrentMap的实现，对每个桶使用一个锁，这样就可以支持多个并发写了，当然前提是hashcode映射到了不同的锁上。
分离锁这种办法很适用于竞争相同锁，但是竞争的不是相同数据的程序。

独占锁替代方式

热点域是使用了分离锁之后的，仍然避免不了的全局锁。ConcurrentHashMap的size()方法避免了热点域，给每个桶单独维护了一个计数器。
ReadWriterLock 这样支持读并发，但是有写就阻塞的锁形式
用原子变量来减少热点域带来的并发损失

监测CPU使用率

为了监测我们的处理器是否充分利用，可以监测CPU使用率，如果太过于清闲了，可以看看是不是如下的原因：
- 负载不够。 加大并发量
- I/0限制 perfmon来查看是否是因为带宽限制
- 外部限制，通过Profiler工具来判断等待外部服务结果的用时
- 锁竞争，使用Profiling，查看程序中存在多少个锁的竞争。

用后台程序处理任务

比如log,单启线程来进行打印操作，使用线程池和队列的方式。需要考虑如下的问题：
- 服务担保， 保证成功加入队列的消息都能在服务终止前被记录？
- 饥饿策略，如果生产者比消费者快怎么办？
- 生命周期， 如果在服务器停止的时候关闭消费者
- 中断，如果线程被中断(如服务器重启)会怎么办