Отклонения в производительности для небольшого метода

Question

У нас есть контейнер OSGi с множеством продуктов, работающих внутри, один из которых является нашим продуктом.
У нас есть некоторые тесты производительности, и есть такая странная проблема, что при каждом перезагрузке контейнера OSGi для некоторых наших тестов до 400% будет отклоняться производительность.
Через некоторое тестирование и вещей, которые я был в состоянии отслеживать это вниз к этому методу:

public static Method getMethodForSlotKey(Class<?> cls, String slotKey, String methodType) { 

    Method[] methods = cls.getMethods(); 

    if (methods != null && methods.length > 0) { 
     for (Method method : methods) { 
      String methName = method.getName(); 
      if (methName.startsWith(methodType)) { 

       IDataAnnotation annot = method.getAnnotation(IDataAnnotation.class); 
       if (annot != null) { 
        String annotSlotKey = annot.SlotKey(); 
        if (annotSlotKey != null && annotSlotKey.equals(slotKey)) { 
         Class<?>[] paramTypes = method.getParameterTypes(); 
         // for now, check length == 1 for setter and 0 for getter. 
         int len = SET_TXT.equals(methodType) ? 1 : 0; 
         if (paramTypes != null && paramTypes.length == len) { 
          return method; 
         } 
        } 
       } 
      } 
     } 
    } 
    return null; 
} 

Этот метод в основном делает отражение и сравнение строк.

Теперь, я сделал это, чтобы кэшировать результаты этого метода, и мгновенно наше отклонение снижается до 10-20%. Конечно, этот метод часто называют, так что улучшение улучшается.

По-прежнему я не понимаю, почему не кэшированная версия имеет такое высокое отклонение с той лишь разницей, что перезапуск OSGi/JVM? Что именно может произойти во время перезапуска? Существуют ли какие-либо известные проблемы производительности для разных загрузчиков классов? Возможно ли, что в библиотеках среды OSGi будут загружены в другом порядке между перезапусками?

Я ищу ключ, чтобы это имело смысл.

UPDATE

Оказывается, что этот призыв:

Method[] methods = cls.getMethods(); 

вызывает отклонение. Я до сих пор не понимаю этого, поэтому, если кто-нибудь сделает это, я буду рад услышать об этом.

Answer 1

Я подозреваю, что это связано с тем, что перезагрузка вашего сервера/контейнера OSGi очищает кэшированный Method[] * в классах, которые вы запрашиваете. Кэш будет очищен, чтобы обеспечить правильную работу в ситуации, когда перезагруженный класс имеет другой открытый API (то есть разные методы), чем старый с тем же именем (это может произойти, например, при загрузке более новой версии)

Когда вы реализуете свой кеш своего метода «обертка», вы обходите это и представляете предположение, что перезагруженные классы будут иметь те же методы, что и ранее загруженные классы с тем же именем. Вероятно, это довольно безопасное предположение для большинства случаев, но не одно, которое вы бы хотели создать для Java.

Исходный код (OpenJDK) Class класс is here. Если вы просмотрите его, вы увидите, что getMethods() звонит privateGetPublicMethods(). Если массив кэшированных publicMethods равен NULL или сделан нулевым значением clearCachesOnClassRedfinition(), тогда классу придется пройти относительно интенсивный процесс поиска всех общедоступных методов в классе и любых суперклассов, на которые он наследует, и интерфейсов, которые он реализует. Затем он кэшируется, и скорость getMethods() вернется к норме.

* строгое, кешированное значение является мягкой ссылкой на массив.

Answer 2

Кажется, что это еще один случай сложного JIT, который, кажется, постоянно меняется и развивается со временем.Этот ответ может пролить свет на вашу проблему: Java: what is JITC's reflection inflation?

Я считаю, что вы наблюдаете последствия после того, как JIT оптимизирует ваши рефлекторные звонки. Некоторое время (первые вызовы X) будет медленным, пока JIT не решит оптимизировать ваш метод.

Что-то, что вы можете попробовать - проверить эту теорию - это изменить ваш код и поместить нарушающий вызов в фиктивный цикл и выполнить его несколько раз при первом вызове (убедитесь, что вы что-то сделали с результатом вызов заставить java не полностью отключить вызов, если он показывает, что он не имеет последствий). Если это приводит к очень длительному времени выполнения для первого использования, а затем к очень низкой дисперсии последующих вызовов, то теория звучит правильно.