性能/可伸缩性

亦凉 2022-03-27 01:24 241阅读 0赞

先考虑代码的正确，安全，再考虑性能（用更少资源做更多事情）。  
利用现有资源，出现新的资源能否利用，尽可能保持cpu有效忙碌  
性能两个方面：  
快（服务，延迟时间）  
多少（处理能力，吞吐量像qps或tps这种,可伸缩性）,服务器应用关注的重点  
可伸缩性：增加资源（cpu，内存等），吞吐量能否相应增加，这方面调优考虑计算并行化  
多快和多少之间的矛盾：如分层架构，对单个任务执行更慢（执行过程分解，任务排队，网络传输等等），但它却有更好的可伸缩性, 我们应采用。  
Amdahl定律：最高加速比取决于串行工作所占比例，串行10%，9cpu，最高加速比5， 无限cpu，最高加速比接近10  
并发程序一定存在串行部分（比如各线程从共享队列取任务需同步，结果写入或合并），这些串行部分影响加速比进而限制了可伸缩性  
多线程额外开销：线程创建销毁，调度及上下文切换，协调（加锁，信号，内存同步）  
上下文切换：jvm和操作系统代码占据不少cpu时间，缓存丢失，不能过于频繁（最小执行时间），很多阻塞导致了上下文切换，吞吐量下降  
内存同步：synchronized/volatile 提供的内存栅栏指令（抑制编译器优化/指令重排序，缓存处理），区分无竞争同步（开销很低）和有竞争同步（性能瓶颈，优化重点），jvm优化：同步消除（基于逃逸分析），锁粒度粗化（相邻同步块合一）  
阻塞: 竞争锁失败阻塞，阻塞实现：可自旋或操作系统挂起（带来上下文切换）  
在锁上发生竞争：1 串行和可伸缩性问题 2 上下文切换和性能问题  
降低锁上竞争：  
1 持有锁时间（同步块小点，一些长时间代码移出去）  
2 请求锁频率  
锁分解：独立的变量可用多个锁保护，一拆二，很多时候我们只是在锁上竞争，并没有在数据上竞争  
锁分断：竞争依然激烈，进一步扩展，ConcurrentHashMap（大部分读不加锁）,N个桶用(N mod 16)号锁来保护，问题是某些情 况（扩容）必须获取所有锁  
热点域：如HashMap为了size从O(n)降到O(1)，各种操作如put或remove都会去更新size，size变成了热点 域， 热点域提升了性能，但带来了可伸缩性问题（大家都访问它，若同步情况下就是串行），ConcurrentHashMap为每个分段单独维护计数  
3 放弃独占锁，或协调机制的独占锁，如ReadWriteLock，原子变量等  
监控cpu利用率，cpu没有充分利用（负载不够，锁，IO），CPU充分利用，那么增加cpu能否提升性能？  
对象池的问题：对象复用，分配对象开销不大（cas指针碰撞或tlab在各线程自己堆空间分配），而从对象池获取交还对象需同步（可伸缩性）  
synchronizedMap：多线程反而吞吐量下降，同一时刻只有一个线程能运行，不少cpu时间用在上下文切换上  
ConcurrentHashMap : 多线程吞吐量上升  
考虑将发生阻塞（上下文切换）的操作（记录日志时等待io甚至等待输出流上的锁）移出服务线程，放入后台线程。