为什么我不能直接访问（并锁定）Objects用于synchronized块的隐式锁

问题描述

重新定义

我希望能够通过调用锁定来混合使用synchronized块和更明确的锁定适当时直接发布方法。因此允许我使用sychtronized（myObject）的合成糖，当我可以逃脱它，但也能够调用myObject.lock& myObject.unlock dierctly，当一个synchronized块不够灵活，无法完成我需要做的事情。

I would like to be able to mix the use of the synchronized block with more explicit locking via calling lock and release methods directly when appropriate. Thus allowing me the syntaxtical sugar of using sychtronized(myObject) when I can get away with it, but also being able to call myObject.lock & myObject.unlock dierctly for those times when a synchronized block is not flexible enough to do what I need done.

我知道每个Object都隐含地内置了一个内置的租用锁，并由synchronized块使用。每次进入同步块时，有效地锁定对象内部可重入锁定的锁定方法，并在离开同步块时在同一可重入锁定上调用解锁。我觉得好像很容易让人能够手动锁定/解锁这个明显的重入锁;因此允许混合同步块和explcit锁定。

I know that every single Object has, implicitly, a rentrant lock built into it which is used by the synchronized block. Effectively the the lock mthod is caled on the Objects internal reentrant lock every time one enters a sychronized block, and unlock is called on the same reentrant lock when you leave the synchronized block. I would seem as if it wouldn be easy enough to allow one the ability to manually lock/unlock this inplicit reentrant lock; thus allowing a mixing of synchronized blocks and explcit locking.

但是，据我所知，没有办法做到这一点。并且由于同步块的工作方式，我不相信有一种方便的方法将它们与显式锁定othewrise混合。这似乎是一个相当方便，并通过扩展Object api添加锁定/解锁方法轻松添加。

However, as far as I know there is no way to do this. And because of the way synchronized blocks work I don't believe there is a convenient way to mix them with explicit locking othewrise. It seems as if this would be a rather convenient, and easily added by expending the Object api to add lock/unlock methods.

我的问题是，为什么没有'这存在吗？我确定有理由，但我不知道它是什么。我认为这个问题可能与封装有关;同样的原因，你不想做同步（这）。但是，如果我已经调用了sycnhronized（myObject），那么通过定义任何知道myObject的人都可以同步它，并且如果愚蠢地执行就会导致死锁。封装问题归结为谁可以访问您同步的对象，无论您使用sychtronized块还是手动锁定对象;至少我认为如此。那么还有一个其他优点就是不允许手动锁定一个对象吗？

The question I have is, why doesn't this exist? I'm certain there is a reason, but I don't know what it is. I thought the issue may be with encapsulation; same reason you don't want to do synchronize(this). However, if I am already calling sycnhronized(myObject) then by defination anyone who knows about myObject can likewise synchronize on it and cause a deadlock if done foolishly. The question of encapsulation comes down to who can access the object you synchronized on regardless of rather you use a sychtronized block or manually locked the object; at least as I see it. So is there some other advantage to not allowing one to manually lock an object?

推荐答案

某个对象的锁是高度捆绑的实例本身。 synchronized 块和方法的结构非常严格。如果您作为程序员，可能会干扰系统（虚拟机），则可能会导致严重问题。

The locks of a certain object is highly tied to the instance itself. The structure of the synchronized blocks and methods are very strict. If you, as a programmer, would have the possibility to interfere with the system (virtual machine), it could cause serious problems.

• 您最终可以释放由 synchronized 块创建的锁


• 您创建另一个 synchronized 块将发布


• 您创建的锁定条目多于退出


• 您创建的锁定退出次数多于条目

• You could eventually release a lock that was created by a synchronized block
• You create a lock that another synchronized block will release
• You create more lock entries than exits
• You create more lock exits than entries

甚至为 lock 和发布版本定义了特定的字节码运营。如果你有这个锁定/解锁操作的方法，它应该被编译为这些字节码。因此，真的是一个低级操作，与其他Java对象级实现非常不同。

There are even specific bytecodes defined for the lock and release operations. If you would have a "method" for this lock/unlock operation, it should be compiled to these bytecodes. So, it is really a low-level operation, and very much different from other Java object level implementations.

同步是一个非常强大的契约。我认为JLS的设计者不希望允许违反这个合同。

Synchronisation is a very strong contract. I think that the designers of the JLS did not want to allow the possibility to break this contract.

描述了有关预期行为的更多信息。

The Chapter 17 of the JLS describes more about the expected behaviour.

这篇关于为什么我不能直接访问（并锁定）Objects用于synchronized块的隐式锁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！