为什么调用方法的Java字节码隐式获取和释放监视器？ [英] Why do the Java bytecodes for invoking methods implicitly acquire and release monitors?

问题描述

我一直在阅读 Java虚拟机指令集并注意到当使用指令来调用标记为同步的方法（例如invokestatic，invokevirtual等）时，由特定的字节码指令来获取接收器对象上的监视器。类似地，从方法返回时，由方法同步时指令释放监视器的指令。这看起来很奇怪，因为有明确的monitorenter和monitorexit字节码来管理监视器。 JVM是否有特殊原因以这种方式设计这些指令，而不是仅仅编译方法以包含适当的monitorenter和monitorexit指令？

I've been reading up on the Java Virtual Machine Instruction Set and noticed that when using instructions to invoke methods (e.g. invokestatic, invokevirtual, etc.) that are marked synchronized, it's up to that particular bytecode instruction to acquire the monitor on the receiver object. Similarly, when returning from a method, it's up to the instruction that leaves the method to release the monitor when the method is synchronized. This seems strange, given that there are explicit monitorenter and monitorexit bytecodes for managing monitors. Is there a particular reason for the JVM designing these instructions this way, rather than just compiling the methods to include the monitorenter and monitorexit instructions where appropriate?

推荐答案

早在90年代中期，就没有Java JIT编译器和微同步被认为是一个非常好的主意。

Back in the mid-90s, there were no Java JIT compilers and micro-synchronisation was thought to be a really great idea.

所以你打电话这些同步方法很多。即使 Vector 也有！您可以在没有额外字节码的情况下进行处理。

So you are calling these synchronised method a lot. Even Vector has 'em! You could deal without the extra bytecodes to interpret.

但不仅仅是在运行代码时。类文件更大。额外的说明，但也设置尝试 / 最后表和验证顽皮的东西没有被插入。

But not just when the code is being run. The class file is bigger. Extra instructions, but also setting up the try/finally tables and verification that something naughty hasn't been slipped in.

只是我的猜测。

这篇关于为什么调用方法的Java字节码隐式获取和释放监视器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！