[-128, 127] to a function that takes a <code>byte</code> as an argument.
+<h2>Monitor Verification</h2>
+
+<p>
+If a method locks an object with a <code>synchronized</code> statement, the
+object must be unlocked before the method returns. At the bytecode level,
+this means the method must execute a matching <code>monitor-exit</code>
+for every <code>monitor-enter</code> instruction, whether the function
+completes normally or abnormally. The bytecode verifier optionally
+enforces this.
+
+<p>
+The verifier uses a fairly simple-minded model. If you enter a monitor
+held in register N, you can exit the monitor using register N or any
+subsequently-made copies of register N. The verifier does not attempt
+to identify previously-made copies, track loads and stores through
+fields, or recognize identical constant values (for example, the result
+values from two <code>const-class</code> instructions on the same class
+will be the same reference, but the verifier doesn't recognize this).
+
+<p>
+Further, you may only exit the monitor most recently entered. "Hand
+over hand" locking techniques, e.g. "lock A; lock B; unlock A; unlock B",
+are not allowed.
+
+<p>
+This means that there are a number of situations in which the verifier
+will throw an exception on code that would execute correctly at run time.
+This is not expected to be an issue for compiler-generated bytecode.
+
+<p>
+For implementation convenience, the maximum nesting depth of
+<code>synchronized</code> statements has been set to 32. This is not
+a limitation on the recursion count. The only way to trip this would be
+to have a single method with more than 32 nested <code>synchronized</code>
+statements, something that is unlikely to occur.
+
+
<h2>Verification Failures</h2>
<p>
OSDN Git Service
