当前位置 : 主页 > 编程语言 > java >

Thread专题(10) - 性能和可伸缩性

来源:互联网 收集:自由互联 发布时间:2022-10-15
此文被笔者收录在系列文章 ​​​架构师必备(系列)​​ 中 设计并发程序时,性能并不是最优先的考虑,安全总是放在第一位的。首先要保证程序的正确性,而后只有当你的性能需

此文被笔者收录在系列文章 ​​​架构师必备(系列)​​ 中

设计并发程序时,性能并不是最优先的考虑,安全总是放在第一位的。首先要保证程序的正确性,而后只有当你的性能需求和评估标准需要程序运行得更快时,才去进行改进。

一、性能的思考

改进程序的目的就是为了充分利用硬件的能力,所以测试时我们要尽量分析CPU的问题还是内存的问题;1、要有效的利用我们现有的资源;2、出现新的问题时能更有效的利用现有资源。有时经过测试后,可调节线程池大小的多线程程序的池最适合大小为1,这时多线程的设计就属于多余的。

性能遭遇可伸缩性

应用程序可以从很多角度来衡量:比如服务时间、等待时间、吞吐量、效率、可伸缩性、生产量,可伸缩性指的是当增加计算资源(硬件)的时候,吞吐量和生产量能够相应地得以改进。为伸缩性进行调试的时候目的是能够利用额外的计算资源,用更多的资源做更多的事情。

在结构和性能之间需要权衡来考虑,性能有多快和有多少任务协同要分别进行调试。很多单线程调优的方式,在多线程程序中都会起到反作用。传统的三层程序,虽然结构清晰,但是存在队列、协调、数据拷贝的开销。

对性能的权衡进行评估

有时候优化会违背面向对象的设计原则。通常来讲越快的程序越复杂,也就越难以维护。在决定优化一个程序之前,可以保守地问下以下问题:

1、所谓的“快”指的是什么。

2、在什么样的条件下你的方案能够真正运行的更快?在轻负载还是重负载下?等

3、这些条件在你的环境中发生的频率?

4、这些代码在其他环境的不同条件下可被复用的可能性?

5、你用什么样隐含的代价,比如增加的开发风险或维护性,换取了性能的提高?

我们通常在优化程序时很多时候都是靠直觉。我们可以借助一些工具,比如perfbar来测试。

二、Amdahl定律

使用线程的重要原因之一是为了支配多处理器的能力,我们必须保证问题被恰当地进行了并行化的分解,并且我们的程序有效地使用了这种并行的潜能。

这个定律描述的是,程序是由一系列并行和串行化的片断组成。基于可并行化和串行化的组件各自所占的比重,程序通过获得额外的计算资源,我们最多可以加速:

Speedup<=1/(F+(1-F) / N):F指串行化程序的比重,N指处理器的个数。

当N无限增大趋近无穷时,这意味着如果50%的处理都需要串行进行的话,speedup只能提升2倍。如果程序的10%需要串行进行,speedup最多能够提高近10倍。

Amdahl同样量化了串能行化的效率开销,有有10个处理器的系统中,如果10%的程序是串行化,那么最多可以加速5.3倍,在100个处理器的系统中,可以达到9.2倍。

我们在写一些多线程的程序时,如果想提高性能,最好的办法是要充分了解各个容器类的原理,然后再加以利用。 任务执行的时间除了运算时间,还有从共享容器中取出数据的时间。充分发现串行源,可以预先估算速度。一般来说,并发数和CPU数是一对一的(并不绝对)。

三、线程引入的开销

如果可运行的线程数超过CPU的个数,就会发生上下文切换。此时即使有很多其他正在等待的线程,调度程序也会为每一个可运行的线程分配一个最小执行时间的定额,就是这个原因:它分期偿付切换上下文的开销,获得更多不中断的执行时间,从整体上提高了吞吐量。当线程因为竞争一个锁而阻塞时,JVM通常会将这个线程换出。

一般来讲处理器上下文切换的开销相当于5000-10000个时钟周期即几微秒。UNIX可以用vmstat查看切换次数。高内核占用率超过10%时就象征着频繁的调度活动,可能是I/O阻塞或是竞争锁引起的。

不要过分担心非竞争的同步带来的开销,硬件的基础机制已经足够快了,在这个基础上,JVM能够进行额外的优化,大大减少或消除了开销,我们只需要关注那些真正发生的锁竞争在区域中性能的优化。

减少上下文切换的开销

这处要根据实际情况来设计自己的程序,比如日志的例子大多数日志框架都是围绕println进行瘦包装的,另一种方案就是日志记录的工作由一个专职的后台线程完成。后一种方式是比较好的方式。构建一个logger,它会把I/O移到另一个线程,这样可以提高性能,但也会引入更多的设计复杂度,比如中断、服务担保、饥饿策略、服务的生命周期。

四、减少锁的竞争

串行化、上下文切换以及锁竞争都会影响可伸缩性,在并发程序中,可伸缩性的最大威胁是独占的资源锁。有两个原因影响着锁的竞争性,锁被请求的频率以及每次持有该锁的时间,如果这两者的×积足够小,那么大多数请求锁的尝试都是非竞争的。

有几种方式可以减少锁的竞争:1、减少持有锁的时间;2、减少请求锁的频率;3、用协调机制取代独占锁。

缩小锁的范围(快进快出)

减小竞争发生可能性的有效方式是尽可能缩短把持锁的时间,可以通过把与锁无关的代码移出synchronized块来实现,尤其是那些昂贵的操作,以及潜在的阻塞操作。比如下面一个例子,只有map一行代码是需要同步的。

理论上把一个大的synchronized拆分成多个小synchronized是能提高性能的,实际上是与平台相关的,如果JVM进行了锁的粗化,这种拆分是无效的,仅当能够“切实”地把计算和阻塞操作从synchronized块中移开时才会有意义。

public synchronized boolean userLocationMatches(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 userLocationMatches(String name, String regexp) {
String key = "users." + name + ".location";
String location;
synchronized (this) {
location = attributes.get(key);
}
if (location == null)
return false;
else
return Pattern.matches(regexp, location);
}

减小锁的粒度(定义多个不同功能的锁)

减小持有锁的时间比例的另一种方式是让线程减小调用它的频率,可以通过分拆锁和分离锁来实现,采用相互独立的锁来守护相互独立的状态变量,但同时更多的也增加了死锁的风险。

如果一个锁守卫数量大于一、且相互独立的状态变量,你可能能够通过分拆锁,使每一个锁守护不同的变量,从而改进伸缩性,结果是每个锁被请求的频率都减小了。分拆锁例子如下:这个例子中users和queries是相互独立的,分拆锁适合原来竞争并不激烈的锁来进行优化。

public class ServerStatusBeforeSplit {
@GuardedBy("this") public final Set<String> users;
@GuardedBy("this") public final Set<String> queries;
public ServerStatusBeforeSplit() {
users = new HashSet<String>();
queries = new HashSet<String>();
}
public synchronized void addUser(String u) {
users.add(u);
}
public synchronized void removeQuery(String q) {
queries.remove(q);
}
}public class ServerStatusAfterSplit {
@GuardedBy("users") public final Set<String> users;
@GuardedBy("queries") public final Set<String> queries;

public ServerStatusAfterSplit() {
users = new HashSet<String>();
queries = new HashSet<String>();
}
public void addUser(String u) {
synchronized (users) {
users.add(u);
}
}
public void removeUser(String u) {
synchronized (users) {
users.remove(u);
}
}
}

分离锁(同样功能的锁拆分成多把锁)

把一个竞争锁分拆成两个,很可能形成两个竞争激烈的锁,也可以改进伸缩性,但这仍然不能大幅地提高多个处理器在同一系统中并发性的前景。分拆锁有时可以被扩展,分成可大可小加锁块的集合,并且它们归属相互独立的对象,这样的情况称为分离锁。

ConcurrentHashMap的实现使用了一个包含16个锁的Array,每一个锁都守护Hash Bucket的1/16,Bucket N由第N mod 16个锁来守护,并且这些关键字能够以统一的方式访问,这将会把对于锁的请求减少到约为原来的1/16,同时也意味着ConcurrentHashMap最多可以同时被16个线程writer。

分离锁的一个负面作用就是:对容器加锁,进行独占访问时更加困难,获得内部锁的一个任意集合的唯一方式是递归。

避免热点域

上述两种技术可以改变伸缩性,当每一个操作都请求变量的时候,锁的粒度很难被降低。这是性能和伸缩性相互牵制的另一个方面,通常使用的优化方法是引入“热点域”。比如Map实现的size方法,size()的实现就是当每改变一次Map就缓存一次size的值,虽然会使size方法的开销从O(n)减小到O(1),但这样实现后会限制伸缩性。这时这个共享的全局计数量就称为“热点域”,因为对Map的每次操作都要改变它,程序中应该避免这种情况发生,比如ConcurrentHashMap的size实现是通过枚举每个条目获得size,并把这个值加入到每个条目,而不是共享一个独立的计数器。

伸缩性指保持处理器的充分利用,并行可以运行更多的线程的能力。

public class StripedMap {
// Synchronization policy: buckets[n] guarded by locks[n%N_LOCKS]
private static final int N_LOCKS = 16;
private final Node[] buckets;
private final Object[] locks;

private static class Node {
Node next;
Object key;
Object value;
}

public StripedMap(int numBuckets) {
buckets = new Node[numBuckets];
locks = new Object[N_LOCKS];
for (int i = 0; i < N_LOCKS; i++)
locks[i] = new Object();
}

private final int hash(Object key) {
return Math.abs(key.hashCode() % buckets.length);
}

public Object get(Object key) {
int hash = hash(key);
synchronized (locks[hash % N_LOCKS]) {
for (Node m = buckets[hash]; m != null; m = m.next)
if (m.key.equals(key))
return m.value;
}
return null;
}

public void clear() {
for (int i = 0; i < buckets.length; i++) {
synchronized (locks[i % N_LOCKS]) {
buckets[i] = null;
}
}
}
}

监测CPU利用率

CPU不均匀的利用率说明,大多数计算都由很小的线程集完成,这时应该增加程序的并发性。可能由以下几种原因:

1、不充足和负载测试,这时要再加入足够多的负载。

2、I/O限制,是否受限于磁盘还是网络。

3、外部限制,比如数据库。

4、锁竞争,使用Profiling可以看出程序中存在多少个锁竞争。

“对象池”不适用的场景

用线程池的技术来人为减小创建对象的开锁,防止GC回收这样的性能开锁。在单线程程序中,也只有对重量级的对象有性能提升。在多线程并发的应用程序中,池化表现得很糟糕,因为池要管理很多东西,池化在多线程程序的使用中也是有局限性的。分配对象通常比同步对象要便宜。

五、比较Map的性能

单线程化的ConcurrentHashMap的性能要比同步的(synchronized)限制的HashMap的性能要好一些,尤其在并发程序中,ConcurrentHashMap并没有对成功的读操作加锁,对写操作和真正需要锁的读操作使用了分离锁的方法。因此并发的程序能够并发访问ConcurrentHashMap而不被阻塞。

同步容器的数量并不是越多越好,单线程的情况与ConcurrentHashMap一致,但是一旦负载由多数为非竞争的情况变成多数为竞争性的情况---同步的容器会表现的很糟糕。这在锁竞争的代码行为中很常见。只要竞争小,每个操作所花费的时间取决于真正工作的时间,吞吐量会因为线程数的增加而增加。一旦竞争大,每个操作的时间由上下文切换和调试时间决定了,并且加入更多的线程不会对吞吐量有什么帮助。

上一篇:LinkedList源码分析(五)
下一篇:没有了
网友评论