Locking monitor can cause deadlock.

Description:

There is a loop in lock graph.

It can happen that two or more threads will lock monitors in such order, that they will mutually lock each other (thread is waiting for some other monitors while it is also owner of some monitors, preventing threads which owns the monitors it is waiting for to proceed).

This message is produced for each entering monitor statement which corresponds to the edge in lock graph. Also for each such message possible call path from thread entry point is reported.

By default only shortest loop is reported, if you specify report-all-loops message property as true, then all loops will be reported.

To build lock graph, the analyzer performs recursive traverse of call graph starting from thread entry points. By default only run method of classes implementing Runnable interface or extending Thread class are considered as entry point. If you specify all-public-reentrant parameter, then all public methods will be considered as entry points.

When method of some interface is invoked, the analyzer consider that method of any class implementing this interface can be called. By default the analyzer ignore alien classes (i.e. classes which sources are not available for the analysis). This is done to remove false dependencies in lock graph caused by invocation of virtual methods of Object class, such as equals or hashCode. To prohibit such restriction, set override-alien-methods parameter to true.