Что на самом деле сделано в `Ref Enq` в g1 gc

Question

Я нашел пункт журнала gc в моей онлайн-службе hbase следующим образом:

2018-11-08T19:12:35.907+0800: 4069334.381: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 41943040 bytes, new threshold 1 (max 1)
- age   1:   23290768 bytes,   23290768 total
, 1.9809681 secs]
   [Parallel Time: 22.6 ms, GC Workers: 13]
      [GC Worker Start (ms): Min: 4069334380.9, Avg: 4069334381.1, Max: 4069334381.2, Diff: 0.3]
      [Ext Root Scanning (ms): Min: 0.8, Avg: 1.0, Max: 1.1, Diff: 0.3, Sum: 12.8]
      [Update RS (ms): Min: 1.6, Avg: 1.8, Max: 2.0, Diff: 0.4, Sum: 23.4]
         [Processed Buffers: Min: 1, Avg: 4.4, Max: 9, Diff: 8, Sum: 57]
      [Scan RS (ms): Min: 2.2, Avg: 2.4, Max: 2.5, Diff: 0.3, Sum: 30.9]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 6.7, Avg: 7.5, Max: 17.0, Diff: 10.4, Sum: 97.9]
      [Termination (ms): Min: 0.0, Avg: 9.5, Max: 10.3, Diff: 10.3, Sum: 123.1]
         [Termination Attempts: Min: 1, Avg: 2.5, Max: 5, Diff: 4, Sum: 33]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.3]
      [GC Worker Total (ms): Min: 22.1, Avg: 22.2, Max: 22.3, Diff: 0.3, Sum: 288.5]
      [GC Worker End (ms): Min: 4069334403.3, Avg: 4069334403.3, Max: 4069334403.3, Diff: 0.0]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.4 ms]
   [Other: 1957.9 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 4.2 ms]
      [Ref Enq: 1951.7 ms]
      [Redirty Cards: 1.2 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.3 ms]
   [Eden: 592.0M(592.0M)->0.0B(592.0M) Survivors: 32.0M->32.0M Heap: 6521.8M(12.2G)->5943.3M(12.2G)]
 [Times: user=0.19 sys=0.11, real=1.98 secs]

Как вы можете видеть, большинство времени проводят на Ref Enq, Что я могу сделать, чтобы оптимизировать это.

Answer 1

Ответ за заголовок:: Информация о времени, затраченном на обработку опорных объектов, отображается в фазах Ref Proc и Ref Enq. На этапе Ref Proc G1 обновляет референтные объекты эталонных объектов в соответствии с требованиями их конкретного типа. В Ref Enq G1 помещает опорные объекты в их соответствующую опорную очередь, если их референты были найдены мертвыми.

Ответ за оптимизацию:: Если эти фазы занимают слишком много времени, рассмотрите возможность включения распараллеливания этих фаз, используя опцию -XX:+ParallelRefProcEnabled

Для дальнейшей информации --->

https://docs.oracle.com/javase/10/gctuning/garbage-first-garbage-collector-tuning.htm