知识大全使用Java构造高可扩展应用

Posted 2022-07-18 扩展

篇首语：宝剑锋从磨砺出，梅花香自苦寒来。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全使用Java构造高可扩展应用相关的知识，希望对你有一定的参考价值。

使用Java构造高可扩展应用 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　当CPU 进入多核时代之后软件的性能调优就不再是一件简单的事情没有并行化的程序在新的硬件上可能会运行得比从前更慢当 CPU 数目增加的时候芯片制造商为了取得最佳的性能/功耗比降低 CPU 的运行频率是一件非常明智的事情相比 C/C++ 程序员而言利用 Java 编写多线程应用已经简单了很多然而多线程程序想要达到高性能仍然不是一件容易的事情对于软件开发人员而言如果在测试时发现并行程序并不比串行程序快那不是一件值得惊讶的事情毕竟在多核时代之前受到广泛认可的并行软件开发准则通常过于简单和武断

　　在本文中我们将介绍使提高Java 多线程应用性能的一般步骤通过运用本文提供的一些简单规则我们就能获得具有高性能的可扩展的应用程序

　　为什么性能没有增长？

　　多核能带来性能的大幅增长这很容易通过简单的一些测试来观察到如果我们写一个多线程程序并在每个线程中对一个本地变量进行累加我们可以很容易的看到多核和并行带来的成倍的性能提升这非常容易做到不是吗？在参考资源里我们给出了一个例子然而与我们的测试相反我们很少在实际软件应用中看到这样完美的可扩展性阻碍我们获得完美的可扩展性有两方面的因素存在首先我们面临着理论上的限制其次软件开发过程中也经常出现实现上的问题让我们看看图中的三条性能曲线

　　图性能曲线

　　作为追求完美的软件工程师我们希望看到随着线程数目的增长程序的性能获得线性的增长也就是图中的蓝色直线而我们最不希望看到的是绿色的曲线不管投入多少新的 CPU 性能也没有丝毫增长（随着 CPU 增长而性能下降的曲线在实际项目中也存在）而图中的红色线条则说明通常的法则并不适用于可扩展性方面假设程序中有 % 的计算只能串行进行那么其扩展性曲线如红线所示由图可见当 % 的代码可以完美的并行时在个 CPU 存在的情况下我们也只能获得大约倍的性能如果任务中具有无法并行的部分那么在现实世界我们的性能曲线大致上会位于图中的灰色区域

　　在这篇文章中我们不会试图挑战理论极限我们希望能解释一个 Java 程序员如何能够尽可能的接近极限这已经不是一个容易的任务

　　是什么造成了糟糕的可扩展性？

　　可扩展性糟糕的原因有很多其中最为显著的是锁的滥用这没有办法我们就是这样被教育的想要多线程安全吗？那就加一个锁吧想想 Python 中臭名昭著的 Global Intepreter Lock 还有 Java 中的 Collections synchronizedXXXX（）系列方法跟随巨人的做法有什么不好吗？是的用锁来保护关键区域非常方便也较容易保证正确性然而锁也意味着只有一个进程能进入关键区域而其他的进程都在等待！如果观察到 CPU 空闲而软件执行缓慢那么检察一下锁的使用是一个明智的做法

　　对于 Java 程序而言 Performance Inspector 中的 Java Lock Monitor 是一个不错的开源工具

　　[NextPage]

　　对一个多线程应用进行调优

　　下面我们将提供一个例子程序并演示如何在多核平台上获得更好的可扩展性这个例子程序演示了一个假想的日志服务器它接收来自多个源的日志信息并将其统一保存到文件系统中为了简单起见我们的例子代码中不包含任何的网络相关代码 Main（）函数将启动多个线程来发送日志信息到日志服务器中对于性急的读者让我们先看看调优的结果

　　图日至服务器调优结果

　　在上图中蓝色的曲线是一个基于 Lock 的老式日志服务器而绿色的曲线是我们进行了性能调优之后的日志服务器可以看到 LogServerBad 的性能随线程数目的增加变化很小而 LogServerGood 的性能则随着线程数目的增加而线性增长如果不介意使用第三方的库的话那么来自 Project KunMing 的 LockFreeQueue 可以进一步提供更好的可扩展性

　　图使用 Lock free 的数据结构

　　在上图中第三条曲线表示用 LockFreeQueue 替换标准库中的 ConcurrentLinkedQueue 之后的性能曲线可以看到如果线程数目较少时两条曲线差别不大但是单线程数目增大到一定程度之后 Lock Free 的数据结构具有明显的优势

　　在下文中将介绍在上述例子中使用的可以帮助我们创建高可扩展 Java 应用的工具和技巧

　　[NextPage]

　　使用 JLM 分析应用程序

　　JLM 提供了 Java 应用和 JVM 中锁持有时间和冲突统计具体提供以下功能

　　对冲突的锁进行计数

　　成功获得锁的次数

　　递归锁的次数

　　申请锁的线程被阻塞等待的次数

　　锁被持有的累计时间对于支持 Tier Spin Locking 的平台还可以获得以下信息 :

　　请求线程在内层（spin loop）请求锁的次数

　　请求线程在外层（thread yield loop）请求锁的次数

　　使用 rtdriver 工具收集更详细的信息

　　jlmlitestart 仅收集计数器

　　jlmstart 仅收集计数器和持有时间统计

　　jlmstop 停止数据收集

　　jlmdump 打印数据收集并继续收集过程

　　从锁持有时间中去除垃圾收集（Garbage Collection GC）的时间

　　GC 时间从 GC 周期中所有被持有的锁的持有时间中去除

　　使用 AtomicInteger 进行计数

　　通常在我们实现多线程使用的计数器或随机数生成器时会使用锁来保护共享变量这样做的弊端是如果锁竞争的太厉害会损害吞吐量因为竞争的同步非常昂贵

　　volatile 变量虽然可以使用比同步更低的成本存储共享变量但它只可以保证其他线程能够立即看到对 volatile 变量的写入无法保证读修改写的原子性因此 volatile 变量无法用来实现正确的计数器和随机数生成器

　　从 JDK 开始 ncurrent atomic 包中引入了原子变量包括 AtomicInteger AtomicLong AtomicBoolean 以及数组 AtomicIntergerArray AtomicLongArray 原子变量保证了 ++ —— += = 等操作的原子性利用这些数据结构您可以实现更高效的计数器和随机数生成器

　　加入轻量级的线程池—— Executor

　　大多数并发应用程序是以执行任务（task）为基本单位进行管理的通常情况下我们会为每个任务单独创建一个线程来执行这样会带来两个问题一大量的线程（> ）会消耗系统资源使线程调度的开销变大引起性能下降二对于生命周期短暂的任务频繁地创建和消亡线程并不是明智的选择因为创建和消亡线程的开销可能会大于使用多线程带来的性能好处

　　一种更加合理的使用多线程的方法是使用线程池（Thread Pool） ncurrent 提供了一个灵活的线程池实现 Executor 框架这个框架可以用于异步任务执行而且支持很多不同类型的任务执行策略它还为任务提交和任务执行之间的解耦提供了标准的方法为使用 Runnable 描述任务提供了通用的方式 Executor 的实现还提供了对生命周期的支持和 hook 函数可以添加如统计收集应用程序管理机制和监视器等扩展

　　在线程池中执行任务线程可以重用已存在的线程免除创建新的线程这样可以在处理多个任务时减少线程创建消亡的开销同时在任务到达时工作线程通常已经存在用于创建线程的等待时间不会延迟任务的执行因此提高了响应性通过适当的调整线程池的大小在得到足够多的线程以保持处理器忙碌的同时还可以防止过多的线程相互竞争资源导致应用程序在线程管理上耗费过多的资源

　　Executor 默认提供了一些有用的预设线程池可以通过调用 Executors 的静态工厂方法来创建

newFixedThreadPool 提供一个具有最大线程个数限制的线程池 newCachedThreadPool 提供一个没有最大线程个数限制的线程池 newSingleThreadExecutor 提供一个单线程的线程池保证任务按照任务队列说规定的顺序（FIFO LIFO 优先级）执行 newScheduledThreadPool 提供一个具有最大线程个数限制线程池并支持定时以及周期性的任务执行

　　使用并发数据结构

　　Collection 框架曾为 Java 程序员带来了很多方便但在多核时代 Collection 框架变得有些不大适应多线程之间的共享数据总是存放在数据结构之中如 Map Stack Queue List Set 等 Collection 框架中的这些数据结构在默认情况下并不是多线程安全的也就是说这些数据结构并不能安全地被多个线程同时访问 JDK 通过提供 SynchronizedCollection 为这些类提供一层线程安全的接口它是用 synchronized 关键字实现的相当于为整个数据结构加上一把全局锁保证线程安全

　　ncurrent 中提供了更加高效 collection 如 ConcurrentHashMap/Set ConcurrentLinkedQueue ConcurrentSkipListMap/Set CopyOnWriteArrayList/Set 这些数据结构是为多线程并发访问而设计的使用了细粒度的锁和新的 Lock free 算法除了在多线程条件下具有更高的性能还提供了如 put if absent 这样适合并发应用的原子函数

　　[NextPage]

　　其他一些需要考虑的因素

　　不要给内存系统太大的压力

　　如果线程执行过程中需要分配内存这在 Java 中通常不会造成问题现代的 JVM 是高度优化的它通常为每个线程保留一块 Buffer 这样在分配内存时只要 buffer 没有用光那么就不需要和全局的堆打交道而本地 buffer 分配完毕之后 JVM 将不得不到全局堆中分配内存这样通常会带来严重的可扩展性的降低另外给 GC 带来的压力也会进一步降低程序的可扩展性尽管我们有并行的 GC 但其可扩展性通常并不理想如果一个循环执行的程序在每次执行中都需要分配临时对象那么我们可以考虑利用 ThreadLocal 和 SoftReference 这样的技术来减少内存的分配

　　使用 ThreadLocal

　　ThreadLocal 类能够被用来保存线程私有的状态信息对于某些应用非常方便通常来讲它对可扩展性有正面的影响它能为各个线程提供一个线程私有的变量因而多个线程之间无须同步需要注意的是在 JDK 之前 ThreadLocal 有着相当低效的实现如果需要在 JDK 或更老的版本上使用 ThreadLocal 需要慎重评估其对性能的影响类似的目前 JDK 中的 ReentrantReadWriteLock 的实现也相当低效如果想利用读锁之间不互斥的特性来提高可扩展性同样需要进行 profile 来确认其适用程度

　　锁的粒度很重要

　　粗粒度的全局锁在保证线程安全的同时也会损害应用的性能仔细考虑锁的粒度在构建高可扩展 Java 应用时非常重要当 CPU 个数和线程数较少时全局锁并不会引起激烈的竞争因此获得一个锁的代价很小（JVM 对这种情况进行了优化）随着 CPU 个数和线程数增多对全局锁的竞争越来越激烈除了一个获得锁的 CPU 可以继续工作外其他试图获得该锁的 CPU 都只能闲置等待导致整个系统的 CPU 利用率过低系统性能不能得到充分利用当我们遇到一个竞争激烈的全局锁时可以尝试将锁划分为多个细粒度锁每一个细粒度锁保护一部分共享资源通过减小锁的粒度可以降低该锁的竞争程度 ncurrent ConcurrentHashMap 就通过使用细粒度锁提高 HashMap 在多线程应用中的性能在 ConcurrentHashMap 中默认构造函数使用个锁保护整个 Hash Map 用户可以通过参数设定使用上千个锁这样相当于将整个 Hash Map 划分为上千个碎片每个碎片使用一个锁进行保护

　　结论

　　通过选择一种合适的 profile 工具检查 profile 结果中的热点区域使用适合多线程访问的数据结构线程池细粒度锁减小热点区域并重复此过程不断提高应用的可扩展性

cha138/Article/program/Java/gj/201311/27639

知识大全 使用Java构造高可扩展应用

知识大全使用Java构造高可扩展应用