性能与可伸缩性：
对性能的思考：
- 提升性能意味着用更少的资源做更多的事情。
- 资源：CPU, 内存，I/O带宽，网络带宽，数据库请求，磁盘空间等。
性能与可伸缩性：
- 应用程序性能的衡量指标：服务时间，延迟时间，吞吐率，效率，可伸缩性及容量等。
- 可伸缩性指：增加资源时，程序的吞吐量或者处理能力相应地增加。
评估各种性能权衡因素：
- 避免不成熟地优化，首先使程序正确，然后再提高运行速度--如果它还运行得不够快。
- 以测试为基准，不要猜测。
Amdahl定律：
- 在增加计算资源的情况下，程序在理论上能够实现最高加速比，这个值取决于程序中可并行组件与串行组件的比重。
- 见图：
- 对任务队列的串行访问
/**
* 对任务队列的串行访问
*/
public class WorkThread extends Thread {
private final BlockingQueue<Runnable> queue;
public WorkThread(BlockingQueue<Runnable> queue){
this.queue = queue;
}
public void run(){
while (true){
try {
Runnable task = queue.take(); //此处为程序的串行部分
task.run();
} catch (InterruptedException e) {
break;
}
}
}
}- 在所有并发程序中都包含一些串行部分，如果你认为你的程序中不存在串行部分，那么可以再仔细检查一遍。
在各种框架中隐藏的串行部分：
- 不同同步队列吞吐量差异
Amdahl定律的应用：
- 降低锁粒度的技术：锁分解(1个锁分解为2个锁)，锁分段(1个锁分解为多个锁)。
线程引入的开销：
- 对于为了提升性能而引入的线程来说，并行带来的性能提升必须超过并发导致的开销。
上下文切换：
- 切换上下文需要一定的开销，而在线程调度过程中需要访问操作系统和JVM共享的数据结构。
- 上下文切换带来的开销因平台而异，一般情况就是几微秒。
内存同步：
- 同步操作的性能开销包括多个方面，在synchronized和volatile提供的可见性保证中可能会使用一些特殊命令，即内存栅栏。
- 在内存栅栏中，大多数操作都是不能被重排序的。
- JVM可以通过优化来去掉一些不会发生竞争的锁，如：
//object只能由当前线程所访问，所以会去掉锁
synchronized(new Object()){
// do sth.
}
//局部变量v不会逃逸, 因此线程私有，优化会取消加锁
public String getStoogeNames(){
Vector<String> v = new Vector<>();
v.add("Hello");
v.add("World");
return v.toString();
}阻塞：
- 阻塞的线程将包含两次额外的上下文切换：
1. 阻塞时，cpu时间片未用完前被交换出去。
2. 请求的锁或资源可用时，再次被切换回来。
减少锁的竞争：
- 在并发程序中，对可伸缩性的最主要威胁就是独占方式的资源锁。
- 有3中方式可以降低锁的竞争程度：
1. 减少锁的持有时间。
2. 降低锁的请求频率。
3. 使用带有协调机制的独占锁。
减少锁的范围(“快进快出”)：
- 较少锁的持有时间，如将锁无关的代码移出同步块。
/**
* 不必要的长时间持有锁
*/
public class AttrbuteStore {
private final Map<String, String> attributes
= new HashMap<String, String>();
/**
* synchronized锁住当前对象
*/
public synchronized boolean userLocationMatcher(String name, String regexp){
String key = "users." + name + ".location";
String location = attributes.get(key);
if (location == null)
return false;
else
return Pattern.matches(regexp, location);
}
}可修改上面的方法：
public boolean userLocationMatcher(String name, String regexp){
String key = "users." + name + ".location";
String location = null;
synchronized(this){
location = attributes.get(key); //仅锁住共享对象
}
if (location == null)
return false;
else
return Pattern.matches(regexp, location);
}更好的方式是将attributes用并发容器来实现，如ConcurrentHashMap等。
减小锁的粒度：
- 可通过锁分解和锁分段技术来实现。
- 锁分解实例：
/**
* 多个状态由一个锁来保护
*/
public class ServerStatus {
public final Set<String> users;
private final Set<String> queries;
...
public synchronized void addUser(String u){
users.add(u);
}
public synchronized void addQuery(String q){
queries.add(q);
}
}将锁进行分解：
/**
* 多个状态由多个锁来保护
*/
public class BetterServerStatus {
public final Set<String> users;
private final Set<String> queries;
...
public void addUser(String u){
synchronized(users){
users.add(u);
}
}
public void addQuery(String q){
synchronized(queries){
queries.add(q);
}
}
}锁分段：
- 将所分解技术进一步扩展为对一组独立对象上的锁进行分解，这种情况被称为锁分段。
- 实例如ConrrentHashMap的实现：http://my.oschina.net/indestiny/blog/209458
避免热点域：
- 热点域：比如ConcurrentHashMap.size()求元素个数时，是通过枚举每个segment.size累加的，如果你说想单独用一个size来保存元素个数，这样size(), isEmpty()这些方法就很简单了，但同样来一个问题，size的修改会很频繁，切须进行锁保护，反而又降低性能，这时的size 就是一个热点域。
一些替代独占锁的方法：
- 第三种降低竞争锁的影响就是放弃使用独占锁。如并发容器，读写锁，不可变对象，原子变量。
监测CPU的利用率：
- *nix下可用vmstat或mpstat, windows下可用perfmon查看cpu状况。
- cpu利用不充分的原因：
1. 负载不充足。
2. I/O密集。*nix可用iostat, windows用perfmon。
3. 外部限制。如数据库服务，web服务等。
4. 锁竞争。可通过jstack等查看栈信息。
向对象池说"不"：
- 通常，对象分配操作的开销比同步的开销更低。
Map性能比较：
- 建议自行测试一番。
减少上下文切换的开销：
- 任务在阻塞与运行状态间转换时，就相当于一次上下文切换。
- 在任务执行中，尽量减少其服务时间，如一些I/O操作尽量移出同步块，这样可以缩短任务的平均服务时间，从而提高吞吐量。
完。
不吝指正。
