“消除”在Java堆栈跟踪中意味着什么？

Question

我正在查看我的Java应用程序的线程转储，并注意到有时不是显示“已锁定”，我看到关键字“已消除”，如下所示：

"Worker [4]" prio=10 tid=0x00007fb1262d8800 nid=0x89a0 in Object.wait() [0x00007fb15b147000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:503)
        at com.myapp.common.util.WaitableQueue.getAll(WaitableQueue.java:152)
        - eliminated <0x00000004d0d28e18> (a com.myapp.common.util.balq.SingleQueueQController$_WorkerQueue)
        at com.myapp.common.util.balq.SingleQueueQController$_WorkerQueue.getAll(SingleQueueQController.java:3527)
        - locked <0x00000004d0d28e18> (a com.myapp.common.util.balq.SingleQueueQController$_WorkerQueue)
        at com.myapp.common.util.AbstractWorker.read(AbstractWorker.java:678)
        at com.myapp.common.util.AbstractWorker.runBulk(AbstractWorker.java:541)
        at com.myapp.common.util.AbstractWorker.run(AbstractWorker.java:343)

令人惊讶的是，我在Google上找不到任何关于此的内容。 “锁定”和“已删除”关键字之间有什么区别？

Answer 1

它表示已在字节码中删除的冗余锁。

我总是觉得源代码是一个很好的开始这样的事情的地方。 从openJDK回顾hotspot/src/share/vm/opto/callnode.cpp callnode.cpp有以下有趣的评论：

// Redundant lock elimination
//
// There are various patterns of locking where we release and
// immediately reacquire a lock in a piece of code where no operations 
// occur in between that would be observable.  In those cases we can
// skip releasing and reacquiring the lock without violating any
// fairness requirements.  Doing this around a loop could cause a lock
// to be held for a very long time so we concentrate on non-looping
// control flow.  We also require that the operations are fully 
// redundant meaning that we don't introduce new lock operations on
// some paths so to be able to eliminate it on others ala PRE.  This
// would probably require some more extensive graph manipulation to
// guarantee that the memory edges were all handled correctly.
//
// Assuming p is a simple predicate which can't trap in any way and s
// is a synchronized method consider this code:
//
//   s();
//   if (p)
//     s();
//   else
//     s();
//   s();
//
// 1. The unlocks of the first call to s can be eliminated if the
// locks inside the then and else branches are eliminated.
//
// 2. The unlocks of the then and else branches can be eliminated if
// the lock of the final call to s is eliminated.
//
// Either of these cases subsumes the simple case of sequential control flow

因此，从上面看，似乎（至少在openJDK中）消除意味着锁由JVM通过一组或多组释放/获取指令维护。

查看hotspot/src/share/vm/runtime/vframe.cpp中的javaVFrame::print_lock_info_on()显示检查和输出发生的位置：

// Print out all monitors that we have locked or are trying to lock
GrowableArray<MonitorInfo*>* mons = monitors();
if (!mons->is_empty()) {
  bool found_first_monitor = false;
  for (int index = (mons->length()-1); index >= 0; index--) {
    MonitorInfo* monitor = mons->at(index);
    if (monitor->eliminated() && is_compiled_frame()) { // Eliminated in compiled code
      if (monitor->owner_is_scalar_replaced()) {
        Klass* k = Klass::cast(monitor->owner_klass());
        st->print("\t- eliminated <owner is scalar replaced> (a %s)", k->external_name());
      } else {
        oop obj = monitor->owner();
        if (obj != NULL) {
          print_locked_object_class_name(st, obj, "eliminated");
        }
      }
      continue;

包括上述内容在内的其他评论也提到用NOP替换锁定和解锁指令。

我阅读了Dirk提到的关于锁定省略的文件，它似乎是Lock Coarsening而不是Elision：

可用于降低锁定成本的另一个优化是锁定粗化。 锁定粗化是合并使用相同锁定对象的相邻同步块的过程。 如果编译器无法使用锁定省略来消除锁定，则可以通过使用锁定粗化来减少开销。

但说实话，差异非常微妙，最终效果几乎相同 - 你消除了不必要的锁定和解锁。