Мы используем распределенный объект Hazelcast, т.е. IMap, для механизма блокировки через API IMap.trylock (). мы должны получить и снять блокировку для каждого вызова покоя. мы наблюдали значительное влияние на наши звонки для отдыха. При анализе дампа потоков мы видим, что большая часть времени тратится на LockSupport.park (), как указано ниже в различных потоках
"qtp1073885358-4211" - Thread t@4211
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at com.hazelcast.spi.impl.AbstractInvocationFuture.get(AbstractInvocationFuture.java:161)
at com.hazelcast.concurrent.lock.LockProxySupport.tryLock(LockProxySupport.java:138)
at com.hazelcast.map.impl.proxy.MapProxyImpl.tryLock(MapProxyImpl.java:483)
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at com.hazelcast.internal.util.concurrent.MPSCQueue.takeAll(MPSCQueue.java:231)
at com.hazelcast.internal.util.concurrent.MPSCQueue.take(MPSCQueue.java:153)
at com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandlerSupplier$ResponseThread.doRun(InboundResponseHandlerSupplier.java:283)
at com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandlerSupplier$ResponseThread.run(InboundResponseHandlerSupplier.java:272)
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at com.hazelcast.internal.util.concurrent.MPSCQueue.takeAll(MPSCQueue.java:231)
at com.hazelcast.internal.util.concurrent.MPSCQueue.take(MPSCQueue.java:153)
at com.hazelcast.spi.impl.operationexecutor.impl.OperationQueueImpl.take(OperationQueueImpl.java:85)
at com.hazelcast.spi.impl.operationexecutor.impl.OperationThread.run(OperationThread.java:105)
Эти вызовы отнимают много времени. Кто-нибудь сталкивался с подобной проблемой? а что может быть вероятным исправить?