建设一个网站需要哪些硬件设备,关键词查询爱站网,网络优化和推广,网站响应时间长scala和java像不像实际上#xff0c;所有服务器应用程序都需要在多个线程之间进行某种同步。 大多数同步工作是在框架级别为我们完成的#xff0c;例如通过我们的Web服务器#xff0c;数据库客户端或消息传递框架。 Java和Scala提供了许多组件来编写可靠的多线程应用程序。 … scala和java像不像 实际上所有服务器应用程序都需要在多个线程之间进行某种同步。 大多数同步工作是在框架级别为我们完成的例如通过我们的Web服务器数据库客户端或消息传递框架。 Java和Scala提供了许多组件来编写可靠的多线程应用程序。 这些包括对象池并发集合高级锁执行上下文等。 为了更好地理解它们让我们探索最同步的习惯用法-Object lock 。 这种机制为synced关键字提供了动力使其成为Java中最流行的多线程习惯用法之一如果不是。 它也是我们使用的许多更复杂的模式的基础例如线程和连接池并发集合等等。 synced关键字在两个主要上下文中使用 作为方法修饰符用于标记一种方法该方法一次只能由一个线程执行。 通过将代码块声明为关键部分 –在任何给定时间点仅一个线程可以使用一个代码块。 锁定说明 事实1 。 同步代码块使用两条专用字节码指令实现这是官方规范的一部分-MonitorEnter和MonitorExit 。 这与其他锁定机制例如在java.util.concurrent包中找到的锁定机制不同该锁定机制是结合Java代码和通过sun.misc.Unsafe进行的本机调用来实现的对于HotSpot而言。 这些指令对开发人员在同步块的上下文中明确指定的对象进行操作。 对于同步方法锁定将自动选择为“ this ”变量。 对于静态方法锁将放置在Class对象上。 同步方法有时会导致不良行为 。 一个示例是在相同对象的不同同步方法之间创建隐式依赖关系因为它们共享相同的锁。 更糟糕的情况是在基类甚至可能是第3方类中声明同步方法然后将新的同步方法添加到派生类。 这会在整个层次结构中创建隐式同步依赖关系并有可能导致吞吐量问题甚至死锁。 为避免这些情况建议使用私有对象作为锁以防止意外共享或逃脱锁。 编译器和同步 有两个字节码指令负责同步。 这是不寻常的因为大多数字节码指令彼此独立通常通过将值放在线程的操作数堆栈上来彼此“通信”。 还可以从操作数堆栈中加载要锁定的对象该操作数堆栈先前是通过取消引用变量字段或调用返回对象的方法来放置的。 事实2。 那么如果调用这两个指令之一而没有分别调用另一个指令会发生什么呢 如果不调用MonitorEnterJava编译器将不会生成调用MonitorExit的代码。 即使这样从JVM的角度来看这样的代码也是完全有效的。 这种情况的结果是MonitorExit指令抛出IllegalMonitorStateException。 如果通过MonitorEnter获得锁但没有通过对MonitorExit的相应调用释放锁将会发生更危险的情况 。 在这种情况下拥有该锁的线程可能导致其他试图获取该锁的线程无限期地阻塞。 值得注意的是由于该锁是可重入的因此拥有该锁的线程可能会继续愉快地执行即使它再次到达并重新输入相同的锁也是如此。 这就是陷阱。 为了防止这种情况的发生Java编译器以这样的方式生成匹配的输入和退出指令一旦执行已进入同步块或方法它就必须通过匹配的MonitorExit指令来处理同一对象。 可能会引起麻烦的一件事是如果在关键部分内引发了异常。 public void hello() {synchronized (this) {System.out.println(Hi!, Im alone here);}
} 让我们分析一下字节码– aload_0 //load this into the operand stack
dup //load it again
astore_1 //backup this into an implicit variable stored at register 1
monitorenter //pop the value of this from the stack to enter the monitor//the actual critical section
getstatic java/lang/System/out Ljava/io/PrintStream;
ldc Hi!, Im alone here
invokevirtual java/io/PrintStream/println(Ljava/lang/String;)Vaload_1 //load the backup of this
monitorexit //pop up the var and exit the monitor
goto 14 // completed - jump to the end// the added catch clause - we got here if an exception was thrown -
aload_1 // load the backup var.
monitorexit //exit the monitor
athrow // rethrow the exception object, loaded into the operand stack
return 编译器用来防止栈不展开而无需通过MonitorExit指令的机制非常简单–编译器添加了一个隐式的try…catch子句以释放锁并重新抛出异常。 事实三 。 另一个问题是在相应的enter和exit调用之间存储的对锁定对象的引用在哪里。 请记住多个线程可能会使用不同的锁对象同时执行同一同步块。 如果锁定的对象是调用方法的结果则JVM极不可能再次执行它因为它可能会更改对象的状态甚至可能不会返回相同的对象。 对于自输入监视器以来可能已更改的变量或字段情况也是如此。 监视变量 。 为了解决这个问题编译器将一个隐式局部变量添加到方法中以保存锁定对象的值。 这是一个明智的解决方案因为与使用并发堆结构将锁定对象映射到线程该结构本身可能需要同步相比该方法在维护对锁定对象的引用上的开销很小。 在构建Takipi的堆栈分析算法时我首先观察到了这个新变量并发现代码中弹出了意外变量。 注意所有这些工作都是在Java编译器级别完成的。 JVM非常乐意通过MonitorEnter指令进入关键部分而不退出反之亦然或将不同的对象用作对应的enter和exit方法。 锁定在JVM级别 现在让我们更深入地研究如何在JVM级别上实际实现锁。 为此我们将检查HotSpot SE 7的实现因为这是VM特定的。 由于锁定可能会对代码吞吐量产生非常不利的影响因此JVM进行了一些非常强大的优化以尽可能高效地获取和释放锁定。 事实4。 JVM所采用的最强大的机制之一是线程锁偏置 。 锁定是每个Java对象都具有的固有功能就像具有系统哈希码或对其定义类的引用一样。 无论对象的类型如何都是如此如果您愿意甚至可以使用基本数组作为锁。 这些类型的数据存储在每个对象的标头也称为对象的标记中。 保留在对象标题中的某些数据保留用于描述对象的锁定状态。 这包括描述对象的锁定状态即锁定/解锁的位标志以及对当前拥有该锁的线程的引用-指向该对象的线程有偏。 为了节省对象标头中的空间为了减小地址大小并节省每个对象标头中的位64位和32位JVM为54位或23位在VM堆的较低段中分配了Java线程对象。分别。 对于64位– 锁定算法 当JVM尝试获取对象的锁时它会经历从乐观到悲观的一系列步骤。 事实五。 如果线程成功将其自身确立为对象锁的所有者则该线程将获取该锁。 这取决于线程是否能够在对象的标头中安装对自身的引用指向内部JavaThread对象的指针。 获取锁。 使用简单的比较和交换CAS操作即可完成此操作。 这非常有效因为它通常可以转换为直接CPU指令例如cmpxchg。 CAS操作以及OS特定的线程驻留例程用作对象同步习惯用法的构建块。 如果该锁是免费的或者先前已对该线程进行了锁定则将获得该线程的对象锁并且可以立即继续执行。 如果CAS失败则JVM将执行一轮自旋锁定在该循环中线程停放以有效地使其在重试CAS之间进入睡眠状态。 如果这些初始尝试失败向锁发出更高级别的争用信号线程将自身进入阻塞状态并使其自身进入争用该锁的线程列表并开始一系列自旋锁。 在每轮旋转之后线程将检查JVM全局状态的变化例如“停止世界” GC的出现在这种情况下线程将需要暂停自身直到GC完成以防止出现这种情况。在执行STW GC时获得锁并继续执行的位置。 释放锁。 通过MonitorExit指令退出关键部分时所有者线程将尝试查看它是否可以唤醒任何正在等待释放锁的驻留线程。 此过程称为选择“继承人”。 这是为了增加活动性并防止在释放锁也称为绞合的情况下保持线程停放的情况。 调试服务器多线程问题很困难因为它们往往取决于非常特定的时间安排和操作系统启发。 这就是让我们首先从事Takipi工作的原因之一。 参考我们的JCG合作伙伴 Tal Weiss在Takipi博客上对Java和Scala中的同步不了解的5件事 。 翻译自: https://www.javacodegeeks.com/2013/08/5-things-you-didnt-know-about-synchronization-in-java-and-scala.htmlscala和java像不像
