From my analysis, and some of other issues reported speaking about deadlocks (JENKINS-20988, JENKINS-21034, JENKINS-31622, JENKINS-44564, JENKINS-49038, JENKINS-50663, JENKINS-54974), the issue lies in the DescriptorExtensionList, especially in the way it acquires its load lock.
The DescriptorExtensionList getLoadLock method documentation indicates that it is taking part in the real load activity, and that as such, it can lock on this rather than on the singleton Lock used by ExtensionList.

However, many plugins rely on a GlobalConfiguration object, which is acquired through a code similar to the following (which is actually explicitly recommended in GlobalConfiguration documentation).

public static SpecificPluginConfig get() {
    return GlobalConfiguration.all().get(SpecificPluginConfig.class);
}

(the all() method from the GlobalConfiguration is returning a DescriptorExtensionList)

As the configuration for a plugin can be called from many places (initialization of plugin, http requests, ...), it is very easy to have at the same time a DescriptorExtensionList being instantiated, needing in return an ExtensionList, while at the same time, some injection code will have taken the ExtensionList lock and will require DescriptorExtensionList one.
Of course, some other uses of DescriptorExtensionList, not related to GlobalConfiguration, can also create the same kind of issues.

Taking in to account that the lock is only taken when the list is initialized for the first time (in ensureLoaded()), I would say that removing the override of getLoadLock in DescriptorExtensionList should solve the issue at a very minimal cost, or at least make the lock the same as ExtensionList for Descriptor.class