Question

这个问题是关于Java使用偏向锁定的一种方法。下一段是为了未来的读者;我怀疑任何能回答这个问题的人都可以安全地跳过它。

据我所知，曾经有人注意到Java有许多线程安全的类，但其实例往往只被一个线程使用，所以Sun引入了偏向锁定来利用它。麻烦的是，如果你猜错了＆＃34;并尝试偏置需要从两个线程使用的锁，即使没有争用，也需要撤消偏差（＆＃34;撤销＆＃34;），这是如此昂贵以至于JVM努力避免它，即使这意味着有时会错过有偏见的锁定可能是一场净胜利的情况。

我也知道有时候JVM决定做一个＆＃34; bulk＆＃34;重新偏置，并将特定类型的许多锁迁移到不同的线程。这个问题与此无关。出于这个问题的目的，假设我只有两个线程和一个锁。（实际情况更复杂，涉及线程池，但现在让我们忽略它。真的，假装我没有提到它。）进一步假设线程A运行一个无限循环的东西沿着＆＃34;睡眠几秒钟，在锁定下增加整数，重复＆＃34;。（它并不是那么无用，但这应该足以说明问题。）同时，线程B运行类似的循环，但睡眠时间是几个小时而不是几秒钟。进一步假设调度程序是神奇的，并保证永远不会有任何争用。（先发制人的挑剔：如果这是真的，我们可能只是一个不稳定。这只是一个例子。在这里和我一起工作。）这个假设是不现实的，但我一次只想担心一件事。

现在，假设我们关心线程A唤醒和成功递增整数之间的平均延迟。据我所知，JVM最初将锁定偏向A，然后在线程B第一次醒来时撤销偏差。

我的问题是：JVM是否会意识到它的初始猜测基本上是正确的，因此再次将锁重新偏向线程A？

Answer 1

理论上它是可能的，但需要一些额外的条件和特殊的JVM设置。

理论

某些对象的偏向锁定显然无利可图，例如涉及两个或多个线程的生产者 - 消费者队列。这些对象必然具有锁争用。另一方面有将一组对象重新绑定到另一个线程的能力是有利可图的情况，特别是当一个线程分配许多对象时对象并对每个对象执行初始同步操作，但是另一个线程会对它们执行后续工作，例如基于spring的应用程序。

JVM尝试同时涵盖这两个用例并支持rebaising和revocation。请参阅Eliminating Synchronization-Related Atomic Operations with Biased Locking and Bulk Rebiasing

中的详细说明

换句话说，你的理解：

据我了解，JVM最初会将锁定偏向 A，然后在线程B第一次醒来时撤销偏见。

并非总是如此，即JVM足够智能以检测无竞争同步并将锁定重新绑定到另一个线程。

以下是一些实施说明：

HotSpot仅支持批量重新分配以分摊每个对象偏差撤销的成本，同时保留优化的好处。
批量重新绑定和批量撤消共享一个安全点/操作名称 - RevokeBias。这非常令人困惑，需要进一步调查。
后续批量重新订阅当且仅当撤销次数超过BiasedLockingBulkRebiasThreshold且小于BiasedLockingBulkRevokeThreshold并且最新撤销不晚于BiasedLockingDecayTime时，其中所有转义变量都是JVM属性。请仔细阅读this code。
您可以使用属性-XX:+PrintSafepointStatistics跟踪安全点事件。最有趣的是EnableBiasedLocking，RevokeBias和BulkRevokeBias
-XX:+TraceBiasedLocking生成一个有趣的日志，其中详细描述了JVM决策。

实践

这是我的重现器，其中一个线程（实际上是主线程）分配监视器对象并对其执行初始同步操作，然后另一个线程执行后续工作：

package samples;

import sun.misc.Unsafe;

import java.lang.reflect.Field;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static java.lang.System.out;

public class BiasLocking {

    private static final Unsafe U;
    private static final long OFFSET = 0L;

    static {

        try {
            Field unsafe = Unsafe.class.getDeclaredField("theUnsafe");
            unsafe.setAccessible(true);
            U = (Unsafe) unsafe.get(null);
        } catch (Exception e) {
            throw new IllegalStateException(e);
        }
    }


    public static void main(String[] args) throws Exception {

        ExecutorService thread = Executors.newSingleThreadExecutor();

        for (int i = 0; i < 15; i++) {
            final Monitor a = new Monitor();
            synchronized (a) {
                out.println("Main thread \t\t" + printHeader(a));
            }

            thread.submit(new Callable<Object>() {
                @Override
                public Object call() throws Exception {
                    synchronized (a) {
                        out.println("Work thread \t\t" + printHeader(a));
                    }
                    return null;
                }
            }).get();
        }

        thread.shutdown();
    }

    private static String printHeader(Object a) {
        int word = U.getInt(a, OFFSET);
        return Integer.toHexString(word);
    }

    private static class Monitor {
        // mutex object
    }

}

为了重现我的结果，请使用以下JVM参数：

-XX：+ UseBiasedLocking - 默认情况下不需要使用
-XX：BiasedLockingStartupDelay = 0 - 默认情况下会延迟4s
-XX：+ PrintSafepointStatistics -XX：PrintSafepointStatisticsCount = 1 - 启用安全点日志
-XX：+ TraceBiasedLocking - 非常有用的日志
-XX：BiasedLockingBulkRebiasThreshold = 1 - 减少我示例中的迭代次数

在测试过程中，JVM决定重新监视监视器而不是撤销

Main thread         0x7f5af4008805  <-- this is object's header word contains thread id 
* Beginning bulk revocation (kind == rebias) because of object 0x00000000d75631d0 , mark 0x00007f5af4008805 , type samples.BiasLocking$Monitor
* Ending bulk revocation
  Rebiased object toward thread 0x00007f5af415d800
         vmop                    [threads: total initially_running wait_to_block]    [time: spin block sync cleanup vmop] page_trap_count
0.316: BulkRevokeBias                   [      10          0              0    ]      [     0     0     0     0     0    ]  0 
Work thread         0x7f5af415d905  <-- this is object's header word contains thread id => biased

下一步是将锁定重新绑定到主线程。这部分是最难的部分，因为我们必须点击以下heuristics：

  Klass* k = o->klass();
  jlong cur_time = os::javaTimeMillis();
  jlong last_bulk_revocation_time = k->last_biased_lock_bulk_revocation_time();
  int revocation_count = k->biased_lock_revocation_count();
  if ((revocation_count >= BiasedLockingBulkRebiasThreshold) &&
      (revocation_count <  BiasedLockingBulkRevokeThreshold) &&
      (last_bulk_revocation_time != 0) &&
      (cur_time - last_bulk_revocation_time >= BiasedLockingDecayTime)) {
    // This is the first revocation we've seen in a while of an
    // object of this type since the last time we performed a bulk
    // rebiasing operation. The application is allocating objects in
    // bulk which are biased toward a thread and then handing them
    // off to another thread. We can cope with this allocation
    // pattern via the bulk rebiasing mechanism so we reset the
    // klass's revocation count rather than allow it to increase
    // monotonically. If we see the need to perform another bulk
    // rebias operation later, we will, and if subsequently we see
    // many more revocation operations in a short period of time we
    // will completely disable biasing for this type.
    k->set_biased_lock_revocation_count(0);
    revocation_count = 0;
  }

您可以使用JVM参数和我的示例来实现此启发式算法，但请记住，这非常困难，有时需要进行JVM调试。

Java是否会重新锁定单个锁

1 个答案:

理论

实践