同步操作的性能开销包括多个方面。在synchronized和volatile提供的可见性保证中可能会使用一些特殊指令，即内存栅栏〔Memo Barrier)o内存栅栏可以刷新缓存，使缓存无效，刷新硬件的写缓冲，以及停止执行管道。内存栅栏可能同样会对性能带来间接的影响，因为它们将抑制一些编译器优化操作。在内存栅栏中，大多数操作都是不能被重排序的。
在评估同步操作带来的性能影响时，区分有竞争的同步和无竞争的同步非常重要。 synchronized机制针对无竞争的同步进行了优化(volatile通常是非竞争的），而在编写本书时，一个“快速通道(Fast-Path) ”的非竞争同步将消耗20、250个时钟周期。虽然无竞争同步的开销不为零，但它对应用程序整体性能的影响微乎其微，而另一种方法不仅会破坏安全性，而且还会使你（或者后续开发人员）经历非常痛苦的除错过程。
现代的JVM能通过优化来去掉一些不会发生竞争的锁，从而减少不必要的同步开销。如果一个锁对象只能由当前线程访问，那么JVM就可以通过优化来去掉这个锁获取操作，因为另一个线程无法与当前线程在这个锁上发生同步。
一些更完备的JVM能通过逸出分析（EscapeAnalysis）来找出不会发布到堆的本地对象引用（因此这个引用是线程本地的）。在代码getStoogeNames方法中，对List的唯一引用就是局部变量stooges，并且所有封闭在栈中的变量都会自动成为线程本地变量。在 getstoogeNames的执行过程中，至少会将vector上的锁获取/释放4次，每次调用add或 toString时都会执行1次。然而，一个智能的运行时编译器通常会分析这些调用，从而使 stooges及其内部状态不会逸出，因此可以去掉这4次对锁获取操作。
public String getStoogeNames() {
List stooges = new Vector();
stooges.add(“”);
stooges.add(“”);
stooges.add(“”);
return stooges.toString();
}
即使不进行逸出分析，编译器也可以执行锁粒度粗化(Lock Coarsening)操作，即将邻近的同步代码块用同一个锁合并起来。在getstoogeNmnes中，如杲JVM进行锁粒度粗化，那么可能会把3个add与1个toString调用合并为单个锁获取/释放操作，并采用启发式方法来评估同步代码块中采用同步操作以及指令之间的相对开销。这不仅减少了同步的开销，同时还能使优化器处理更大的代码块，从而可能实现进一步的优化。
不要过度担心非竞争同步带来的开销。这个基本的机制已经非常快了，并且JVM还能进行额外的优化以进一步降低或消除开销。因此，我们应该将优化重点放在那些发生锁竞争的地方。
某个线程中的同步可能会影响其他线程的性能。同步会增加共享内存总线上的通信量，总线的带宽是有限的，并且所有的处理器都将共享这条总线。如果有多个线程竞争同步带宽，那么所有使用了同步的线程都会受到影响。
2.3阻塞
非竞争的同步可以完全在JVM中进行处理(Bacon等，1998），而竞争的同步可能需要操作系统的介人，从而增加开销。当在锁上发生竞争时，竞争失败的线程肯定会阻塞。JVM在实现阻塞行为时，可以采用自旋等待(Spin-waiting，指通过循环不断地尝试获取锁，直到成功）或者通过操作系统挂起被阻塞的线程。这两种方式的效率高低，要取决于上下文切换的开销以及在成功获取锁之前需要等待的时间。如果等待时间较短，则适合采用自旋等待方式，而如果等待时间较长，则适合采用线程挂起方式。有些JVM将根据对历史等待时间的分析数据在这两者之间进行选择，但是大多数JVM在等待锁时都只是将线程挂起。
当线程无法获取某个锁或者由于在某个条件等待或在I/O操作上阻塞时，需要被挂起，在这个过程中将包含两次额外的上下文切换，以及所有必要的操作系统操作和缓存操作：被阻塞的线程在其执行时间片还未用完之前就被交换出去，而在随后当要获取的锁或者其他资源可用时，又再次被切换回来。（由于锁竞争而导致阻塞时，线程在持有锁时将存在一定的开销：当它释放锁时，必须告诉操作系统恢复运行阻塞的线程。）
3.减少锁的竞争
============
我们已经看到，串行操作会降低可伸缩性，并且上下文切换也会降低性能。在锁上发生竞争时将同时导致这两种问题，因此减少锁的竞争能够提高性能和可伸缩性。
在对由某个独占锁保护的资源进行访问时，将采用串行方式一一每次只有一个线程能访问它。当然，我们有很好的理由来使用锁，例如避免数据被破坏，但获得这种安全性是需要付出代价的。如果在锁上持续发生竞争，那么将限制代码的可伸缩性。
在并发程序中，对可伸缩性的最主要威胁就是独占方式的锁资源。
有两个因素将影响在锁上发生竞争的可能性：锁的请求频率，以及每次持有该锁的时间。如果二者的乘积很小，那么大多数获取锁的操作都不会发生竞争，因此在该锁上的竞争不会对可伸缩性造成严重影响。然而，如果在锁上的请求量很高，那么需要获取该锁的线程将被阻塞并等待。在极端情况下，即使仍有大量工作等待完成，处理器也会被闲置。
有3种方式可以降低锁的竞争程度：
-
减少锁的持有时间。
-
降低锁的请求频率。
-
使用带有协调机制的独占锁，这些机制允许更高的并发性。
3.1缩小锁的范围（“快进快出”）
降低发生竞争可能性的一种有效方式就是尽可能缩短锁的持有时间。例如，可以将一些与锁无关的代码移出同步代码块，尤其是那些开销较大的操作，以及可能被阻塞的操作，例如l/O操作。
我们都知道，如果将一个“高度竞争"的锁持有过长的时间，那么会限制可伸缩性。如果某个操作持有锁的时间超过2亳秒并且所有操作都需要这个锁，那么无论拥有多少个空闲处理器，吞吐量也不会超过每秒500个操作。如果将这个锁的持有时间降为1毫秒，那么能够将这个锁对应的吞吐量提高到每秒1000 个操作。
下面给出了一个示例，其中锁被持有过长的时间。userLocationMatches方法在一个Map对象中查找用户的位置，并使用正则表达式进行匹配以判断结果值是否匹配所提供的模式。整个userLocationMatches方法都使用了synchronized来修饰，但只有Map.get这个方法才真正需要锁。
在下面的BetterAttributeStore中重新编写了AttributeStore，从而大大减少了锁的持有时间。第一个步骤是构建Map中与用户位置相关联的键值，这是一个字符串，形式为users.name.locationo。这个步骤包括实例化一个StringBuilder对象，向其添加几个字符串，并将结果实例化为一个string类型对象。在获得了位置后，就可以将正则表达式与位置字符串进行匹配。由于在构建键值字符串以及处理正则表达式等过程中都不需要访问共享状态，因此在执行时不需要持有锁。通过在BetterAtfributeStore中将这些步骤提取出来并放到同步代码块之外，从而减少了锁被持有的时间。
通过缩小userLocationMatches方法中锁的作用范围，能极大地减少在持有锁时需要执行的指令数量。根据Amdahl定律，这样消除了限制可伸缩性的一个因素，因为串行代码的总量减少了。
由于在AttributeStore中只有一个状态变量attributes,因此可以通过将线程安全性委托给其他的类来进一步提升它的性能。通过用线程安全的Map（Hashtable、 synchronizedMap或ConcurrentHashMap）来代替attributes，AttributeStore可以将确保线程安全性的任务委托给顶层的线程安全容器来实现。这样就无须在AttributeStore中采用显式的同步，缩小在访问Map期间锁的范围，并降低了将来的代码维护者无意破坏线程安全性的风险（例如在访问attributes之前忘记获得相应的锁）。
尽管缩小同步代码块能提高可伸缩性，但同步代码块也不能过小 一些需要采用原子方式执行的操作（例如对某个不变性条件中的多个变量进行更新）必须包含在一个同步块中。此外，同步需要一定的开销，当把一个同步代码块分解为多个同步代码块时（在确保正确性的情况下），反而会对性能提升产生负面影响。在分解同步代码块时，理想的平衡点将与平台相关，但在实际情况中，仅当可以将一些“大量”的计算或阻塞操作从同步代码块中移出时，才应该考虑同步代码块的大小。
3.2减小锁的粒度
另一种减小锁的持有时间的方式是降低线程请求锁的频率（从而减小发生竞争的可能性）。这可以通过锁分解和锁分段等技术来实现，在这些技术中将采用多个相互独立的锁来保护独立的状态变量，从而改变这些变量在之前由单个锁来保护的情况。这些技术能减小锁操作的粒度，并能实现更高的可伸缩性，然而，使用的锁越多，那么发生死锁的风险也就越高。
设想一下，如果在整个应用程序中只有一个锁，而不是为每个对象分配一个独立的锁，那么，所有同步代码块的执行就会变成串行化执行，而不考虑各个同步块中的锁。由于很多线程将竞争同一个全局锁，因此两个线程同时请求这个锁的概率将剧增，从而导致更严重的竞争。所以如果将这些锁请求分布到更多的锁上，那么能有效地降低竞争程度。由于等待锁而被阻塞的线程将更少，因此可伸缩性将提高。
如果一个锁需要保护多个相互独立的状态变量，那么可以将这个锁分解为多个锁，并且每个锁只保护一个变量，从而提高可伸缩性，并最终降低每个锁被请求的频率。
在程序ServerStatus中给出了某个数据库服务器的部分监视接口，该数据库维护了当前已登录的用户以及正在执行的请求。当一个用户登录、注销、开始查询或结束查询时，都会调用相应的add和remove等方法来更新ServerStatus对象。这两种类型的信息是完全独立的，ServerStatus甚至可以被分解为两个类，同时确保不会丢失功能。
在代码中不是用ServerStatus锁来保护用户状态和查询状态，而是每个状态都通过一个锁来保护，如下图程序所示。在对锁进行分解后，每个新的细粒度锁上的访问量将比最初的访问量少。（通过将用户状态和查询状态委托给一个线程安全的Set，而不是使用显式的同步，能隐含地对锁进行分解，因为每个Set都会使用一个不同的锁来保护其状态。）
如果在锁上存在适中而不是激烈的竞争时，通过将一个锁分解为两个锁，能最大限度地提升性能。如果对竞争并不激烈的锁进行分解，那么在性能和吞吐量等方面带来的提升将非常有限，但是也会提高性能随着竞争提高而下降的拐点值。对竞争适中的锁进行分解时，实际上是把这些锁转变为非竞争的锁，从而有效地提高性能和可伸缩性。
3.3锁分段
把一个竞争激烈的锁分解为两个锁时，这两个锁可能都存在激烈的竞争。虽然采用两个线程并发执行能提高一部分可伸缩性，但在一个拥有多个处理器的系统中，仍然无法给可伸缩性带来极大的提高。
在某些情况下，可以将锁分解技术进一步扩展为对一组独立对象上的锁进行分解，这种情况被称为锁分段。例如，在ConcurrentHashMap的实现中使用了一个包含16个锁的数组，每个锁保护所有散列桶的1/16，其中第个散列桶由第(N mod 16）个锁来保护。假设散列函数具有合理的分布性，并且关键字能够实现均匀分布，那么这大约能把对于锁的请求减少到原来的1/16。正是这项技术使得ConcurrentHashMap能够支持多达16个并发的写入器。（要使得拥有大量处理器的系统在高访问量的情况下实现更高的并发性，还可以进一步增加锁的数量，但仅当你能证明并发写人线程的竞争足够激烈并需要突破这个限制时，才能将锁分段的数量超过默认的16个。）
锁分段的一个劣势在于：与采用单个锁来实现独占访问相比，要获取多个锁来实现独占访问将更加困难并且开销更高。通常，在执行一个操作时最多只需获取一个锁，但在某些情况下需要加锁整个容器，例如当ConcurrentHashMap需要扩展映射范围，以及重新计算键值的散列值要分布到更大的桶集合中时，就需要获取分段所集合中所有的锁。
下面的StripedMap中给出了基于散列的Map实现，其中使用了锁分段技术。它拥有N-LOCKS个锁，并且每个锁保护散列桶的一个子集。大多数方法，例如get，都只需要获得一个锁，而有些方法则需要获得所有的锁，但并不要求同时获得，例如clear方法的实现。
3.4避免热点域
锁分解和锁分段技术都能提高可伸缩性，因为它们都能使不同的线程在不同的数据（或者同一个数据的不同部分）上操作，而不会相互干扰。如果程序采用锁分段技术，那么一定要表现出在锁上的竞争频率高于在锁保护的数据上发生竞争的频率。如果一个锁保护两个独立变量X和Y，并且线程A想要访问X，而线程B想要访问Y（这类似于在ServerStatus中，一个线程调用addUser,而另一个线程调用addQuery），那么这两个线程不会在任何数据上发生竞争，即使它们会在同一个锁上发生竞争。
当每个操作都请求多个变量时，锁的粒度将很难降低。这是在性能与可伸缩性之间相互制 衡的另一个方面，一些常见的优化措施，例如将一些反复计算的结果缓存起来，都会引人一些 “热点域(Hot Field) ”，而这些热点域往往会限制可伸缩性。
当实现HashMap时，你需要考虑如何在size方法中计算Map中的元素数量。最简单的方法就是，在每次调用时都统计一次元素的数量。一种常见的优化措施是，在插人和移除元素时更新一个计数器，虽然这在put和remove等方法中略微增加了一些开销，以确保计数器是最新的值，但这将把size方法的开销从O(n)降低到O(1)。
在单线程或者采用完全同步的实现中，使用一个独立的计数能很好地提高类似size和 isEmpty这些方法的执行速度，但却导致更难以提升实现的可伸缩性，因为每个修改map的操作都需要更新这个共享的计数器。即使使用锁分段技术来实现散列链，那么在对计数器的访问进行同步时，也会重新导致在使用独占锁时存在的可伸缩性问题。一个看似性能优化的措施——缓存size操作的结果，已经变成了一个可伸缩性问题。在这种情况下，计数器也被称为热点域，因为每个导致元素数量发生变化的操作都需要访问它。
为了避免这个问题，ConcurrentHashMap中的size将对每个分段进行枚举并将每个分段中的元素数量相加，而不是维护一个全局计数。为了避免枚举每个元素，ConcurrentHashMap为每个分段都维护了一个独立的计数，并通过每个分段的锁来维护这个值。
3.5一些替换独占锁的方法
第三种降低竞争锁的影响的技术就是放弃使用独占锁，从而有助于使用一种友好并发的方式来管理共享状态。例如，使用并发容器、读·写锁、不可变对象以及原子变量。
ReadWriteLock实现了一种在多个读取操作以及单个写人操作情况下的加锁规则：如果多个读取操作都不会修改共享资源，那么这些读取操作可以同时访问该共享资源，但在执行写人操作时必须以独占方式来获取锁。对于读取操作占多数的数据结构， ReadWriteLock能提供比独占锁更高的并发性。而对于只读的数据结构，其中包含的不变性可以完全不需要加锁操作。
原子变量提供了一种方式来降低更新“热点域"时的开销，例如静态计数器、序列发生器、或者对链表数据结构中头节点的引用。（AtomicLong ）原子变量类提供了在整数或者对象引用上的细粒度原子操作（因此可伸缩性更高），并使用了现代处理器中提供的底层并发原语（例如比较并交换[compare-and-swap])。如果在类中只包含少量的热点域，并且这些域不会与其他变量参与到不变性条件中，那么用原子变量来替代它们能提高可伸缩性。（通过减少算法中的热点域，可以提高可伸缩性——虽然原子变量能降低热点域的更新开销，但并不能完全消除。）
4.减少上下文切换的开销
============
在许多任务中都包含一些可能被阻塞的操作。当任务在运行和阻塞这两个状态之间转换时，就相当于一次上下文切换。在服务器应用程序中，发生阻塞的原因之一就是在处理请求时产生各种日志消息。为了说明如何通过减少上下文切换的次数来提高吞吐量，我们将对两种日志方法的调度行为进行分析。
在大多数日志框架中都是简单地对println进行包装，当需要记录某个消息时，只需将其写人日志文件中。有另一种方法：记录日志的工作由一个专门的后台线程完成，而不是由发出请求的线程完成。从开发人员的角度来看，这两种方法基本上是相同的。但二者在性能上可能存在一些差异，这取决于日志操作的工作量，即有多少线程正在记录日志，以及其他一些因素，例如上下文切换的开销等。
日志操作的服务时间包括与I/O流类相关的计算时间，如果I/O操作被阻塞，那么还会包括线程被阻塞的时间。操作系统将这个被阻塞的线程从调度队列中移走并直到I/O操作结束，这将比实际阻塞的时间更长。当I/O操作结束时，可能有其他线程正在执行它们的调度时间片，并且在调度队列中有些线程位于被阻塞线程之前，从而进一步增加服务时间。如果有多个线程在同时记录日志，那么还可能在输出流的锁上发生竞争，这种情况的结果与阻塞I/O的情况一样——线程被阻塞并等待锁，然后被线程调度器交换出去。在这种日志操作中包含了I/O操作和加锁操作，从而导致上下文切换次数的增多，以及服务时间的增加。
请求服务的时间不应该过长，主要有以下原因。首先，服务时间将影响服务质量：服务时间越长，就意味着有程序在获得结果时需要等待更长的时间。但更重要的是，服务时间越长，也就意味着存在越多的锁竞争。上文3.1节中的“快进快出"原则告诉我们，锁被持有的时间应该尽可能地短，因为锁的持有时间越长，那么在这个锁上发生竞争的可能性就越大。如果一个线程由于等待I/O操作完成而被阻塞，同时它还持有一个锁，那么在这期间很可能会有另一个线程想要获得这个锁。如果在大多数的锁获取操作上不存在竞争，那么并发系统就能执行得更好，因为在锁获取操作上发生竞争时将导致更多的上下文切换。在代码中造成的上下文切换次数越多，吞吐量就越低。
通过将I/O操作从处理请求的线程中分离出来，可以缩短处理请求的平均服务时间。调用 log方法的线程将不会再因为等待输出流的锁或者I/O完成而被阻塞，它们只需将消息放人队列，然后就返回到各自的任务中。另一方面，虽然在消息队列上可能会发生竞争，但put操作相对于记录日志的I/O操作（可能需要执行系统调用）是一种更为轻量级的操作，因此在实际使用中发生阻塞的概更小（只要队列没有填满）。由于发出日志请求的线程现在被阻塞的概率降低，因此该线程在处理请求时被交换出去的概率也会降低。我们所做的工作就是把一条包含I/O操作和锁竞争的复杂且不确定的代码路径变成一条简单的代码路径。
从某种意义上讲，我们只是将工作分散开来，并将I/O操作移到了另一个用户感知不到开销的线程上（这本身已经获得了成功）。通过把所有记录日志的I/O转移到一个线程，还消除了输出流上的竞争，因此又去掉了一个竞争来源。这将提升整体的吞吐量，因为在调度中消耗的资源更少，上下文切换次数更少，并且锁的管理也更简单。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
最后
终极手撕架构师的学习笔记：分布式+微服务+开源框架+性能优化
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
ommunity.csdnimg.cn/images/e5c14a7895254671a72faed303032d36.jpg" alt=“img” style=“zoom: 33%;” />
最后
终极手撕架构师的学习笔记：分布式+微服务+开源框架+性能优化
[外链图片转存中…(img-BhGQKEln-1713446034799)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
扫一扫
688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
