7

众所周知，ReentrantLock有一个最大可重入限制Integer.MAX_VALUE：synchronized块也有可重入限制吗？

更新：我发现很难为同步重入编写测试代码：

public class SyncReentry {
    public static void main(String[] args) {
        synchronized (SyncReentry.class) {
            synchronized (SyncReentry.class) {
                // ...write synchronized block for ever
            }
        }
    }
}

任何人都可以帮助编写一些用于同步重入限制测试的代码吗？

4

2 回答 2

6

由于规范没有定义限制，它是特定于实现的。甚至根本不必有限制，但 JVM 通常会针对高性能进行优化，考虑普通用例而不是专注于对极端情况的支持。

正如在这个答案中所说，对象的内在监视器和 a 之间存在根本区别ReentrantLock，因为您可以在循环中获取后者，这使得有必要指定存在限制。

确定特定 JVM 实现的实际限制，如广泛使用的 HotSpot JVM，存在一个问题，即即使在相同的环境中，也有几个因素会影响结果。

  • 当 JVM 可以证明对象是纯本地的时，JVM 可能会消除锁，即不同的线程不可能在其上同步
  • JVM在使用同一个对象时可能会合并相邻和嵌套的同步块，这可能在内联后应用，因此这些块在源代码中不需要出现嵌套或相互靠近
  • JVM 可能有不同的实现，根据对象类的形状（某些类更可能用作同步键）和特定获取的历史（例如使用偏向锁定，或使用乐观或悲观方法，取决于关于锁被争用的频率）

为了实验实际实现，我使用ASM库生成字节码，循环获取对象的监视器，一个动作，普通Java代码做不到

package locking;

import static org.objectweb.asm.Opcodes.*;

import java.util.function.Consumer;
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.Label;
import org.objectweb.asm.MethodVisitor;

public class GenerateViaASM {
    public static int COUNT;

    static Object LOCK = new Object();

    public static void main(String[] args) throws ReflectiveOperationException {
        Consumer s = toClass(getCodeSimple()).asSubclass(Consumer.class)
            .getConstructor().newInstance();

        try {
            s.accept(LOCK);
        } catch(Throwable t) {
            t.printStackTrace();
        }
        System.out.println("acquired "+COUNT+" locks");
    }

    static Class<?> toClass(byte[] code) {
        return new ClassLoader(GenerateViaASM.class.getClassLoader()) {
            Class<?> get(byte[] b) { return defineClass(null, b, 0, b.length); }
        }.get(code);
    }
    static byte[] getCodeSimple() {
        ClassWriter cw = new ClassWriter(0);
        cw.visit(49, ACC_PUBLIC, "Test", null, "java/lang/Object",
            new String[] { "java/util/function/Consumer" });

        MethodVisitor con = cw.visitMethod(ACC_PUBLIC, "<init>", "()V", null, null);
        con.visitCode();
        con.visitVarInsn(ALOAD, 0);
        con.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "<init>", "()V", false);
        con.visitInsn(RETURN);
        con.visitMaxs(1, 1);
        con.visitEnd();

        MethodVisitor method = cw.visitMethod(
            ACC_PUBLIC, "accept", "(Ljava/lang/Object;)V", null, null);
        method.visitCode();
        method.visitInsn(ICONST_0);
        method.visitVarInsn(ISTORE, 0);
        Label start = new Label();
        method.visitLabel(start);
        method.visitVarInsn(ALOAD, 1);
        method.visitInsn(MONITORENTER);
        method.visitIincInsn(0, +1);
        method.visitVarInsn(ILOAD, 0);
        method.visitFieldInsn(PUTSTATIC, "locking/GenerateViaASM", "COUNT", "I");
        method.visitJumpInsn(GOTO, start);
        method.visitMaxs(1, 2);
        method.visitEnd();
        cw.visitEnd();
        return cw.toByteArray();
    }
}

在我的机器上，它打印

java.lang.IllegalMonitorStateException
    at Test.accept(Unknown Source)
    at locking.GenerateViaASM.main(GenerateViaASM.java:23)
acquired 62470 locks

在一次运行中，但在其他运行中具有相同数量级的不同数字。我们在这里达到的限制不是计数器，而是堆栈大小。例如，在相同的环境中重新运行该程序，但使用该-Xss10m选项，可以获得十倍的锁获取次数。

所以这个数字在每次运行中都不相同的原因，与为什么我可以达到的最大递归深度是不确定的？我们没有得到 a 的原因StackOverflowError是 HotSpot JVM 强制执行结构化锁定，这意味着一个方法必须在获得它的时候准确地释放监视器。这甚至适用于例外情况，并且由于我们生成的代码没有尝试释放监视器，因此StackOverflowError会被IllegalMonitorStateException.

具有嵌套块的普通 Java 代码synchronized在一种方法中永远无法获得接近 60,000 次采集，因为字节码被限制为 65536 字节，并且javac编译synchronized块最多需要 30 字节。但是可以在嵌套方法调用中获取相同的监视器。

对于探索普通 Java 代码的限制，扩展您的问题的代码并不难。你只需要放弃缩进它：

public class MaxSynchronized {
    static final Object LOCK = new Object(); // potentially visible to other threads
    static int COUNT = 0;
    public static void main(String[] args) {
        try {
            testNested(LOCK);
        } catch(Throwable t) {
            System.out.println(t+" at depth "+COUNT);
        }
    }

    private static void testNested(Object o) {
        // copy as often as you like
        synchronized(o) { synchronized(o) { synchronized(o) { synchronized(o) {
        synchronized(o) { synchronized(o) { synchronized(o) { synchronized(o) {
        synchronized(o) { synchronized(o) { synchronized(o) { synchronized(o) {
        synchronized(o) { synchronized(o) { synchronized(o) { synchronized(o) {
            COUNT ++;
            testNested(o);
        // copy as often as you copied the synchronized... line
        } } } }
        } } } }
        } } } }
        } } } }
    }
}

该方法将调用自身以使嵌套获取的数量与嵌套调用的数量乘以synchronized方法内的嵌套块的数量相匹配。

当你像上面那样用少量块运行它时，synchronized你会StackOverflowError在大量调用之后得到一个上面提到的尺寸。-Xcomp-Xint

但是当您synchronized显着增加嵌套块的数量时，嵌套调用的数量会变得更小且稳定。StackOverflowError在我的环境中，当有 1,000 个嵌套块时，它会产生30 次嵌套调用，synchronized而当有 2,000 个嵌套synchronized块时，它会产生 15 次嵌套调用，这非常一致，表明方法调用开销已变得无关紧要。

这意味着超过 30,000 次获取，大约是使用 ASM 生成的代码实现的数量的一半，考虑到javac生成的代码将确保获取和释放的数量匹配，这是合理的，引入了一个合成局部变量来保存对象的引用，该引用必须是为每个synchronized块发布。这个额外的变量减少了可用的堆栈大小。这也是我们现在看到StackOverflowErrorand no的原因IllegalMonitorStateException，因为这段代码正确地执行了结构化锁定。

与另一个示例一样，以更大的堆栈大小运行会提高报告的数量，并线性扩展。推断结果意味着它需要几个 GB 的堆栈大小来获取监控Integer.MAX_VALUE时间。在这些情况下，是否存在限制计数器变得无关紧要。

当然，这些代码示例与现实生活中的应用程序代码相去甚远，因此这里没有进行太多优化也就不足为奇了。对于现实生活中的应用程序代码，锁消除和锁粗化的可能性要高得多。此外，现实生活中的代码将自行执行需要堆栈空间的实际操作，从而使同步的堆栈要求可以忽略不计，因此没有实际限制。

于 2019-02-27T15:35:54.780 回答
2

synchronized不是一个直接的答案，但是由于在同一监视器上（甚至在不同的监视器上）获得大量重新进入块的唯一方法是递归方法调用（例如，您不能以编程方式将其锁定在一个紧密的循环中）你在达到 JVM 内部为此保留的计数器的限制之前，调用堆栈空间将用完。

为什么一个线程只支持 2,147,483,647 我现在也很想知道！

好吧，首先，它已经足够了......但这将通过重新进入计数器来实现，这些东西最终会溢出。

于 2019-02-27T08:42:25.643 回答