Как избежать проблем GeneratedSerializationConstructorAccessor? - PullRequest
Новая
       22

Как избежать проблем GeneratedSerializationConstructorAccessor?

6 голосов
/ 04 июня 2010

У нас есть Java-приложение, которое получает запросы SOAP, и после большого количества запросов мы замечаем, что GC останавливает мир, чтобы выгружать множество классов GeneratedSerializationConstructorAccessor. Это большое влияние на производительность.

Кто-нибудь знает, как этого избежать или хотя бы значительно уменьшить количество созданных классов GeneratedSerializationConstructorAccessor?

Ответы [ 3 ]

5 голосов
/ 04 июня 2010

Используйте один из вариантов: 

-Dsun.reflect.inflationThreshold=30

Увеличивает количество вызовов через конструктор / метод / поле до того, как собственный метод доступа будет «накачан» к сгенерированному средству доступа. По умолчанию установлено значение 15. 

-Dsun.reflect.inflationThreshold=0

Отключает инфляцию в целом. Интересно, что эта опция, похоже, не влияет на конструкторы, но она работает для методов.

Вы можете проверить параметры с помощью простого тестового приложения: 

public class a {
  public static void main(String[] args) throws Exception {
    for (int i = 0; i < 20; i++) {
      a.class.getDeclaredConstructor(null).newInstance(null);
    }
  }

  private static int x;
  public a() {
    new Throwable("" + x++).printStackTrace();
  }
}

Редактировать (29 декабря 2013): Опция -Dsun.reflect.noInflation=true отключает механизм инфляции и вместо этого сразу использует сгенерированные средства доступа, поэтому вам не нужна эта опция.

2 голосов
/ 30 июня 2010

[...] мы замечаем, что ГК останавливает мир, чтобы разгрузить много GeneratedSerializationConstructorAccessor классы. Это большая производительность воздействие.

Поскольку невозможно избежать, если ваше приложение использует рефлексию, вы можете попробовать использовать CMS сборщик мусора , чтобы минимизировать влияние GC "стоп-мир".

0 голосов
/ 04 июня 2010

С http://coding.derkeiler.com/Archive/Java/comp.lang.java.programmer/2006-11/msg00122.html

Эти классы являются частью механизм отражения. Так как вокруг Java 1.3 отражение было реализуется путем генерации классов для выполнить доступ. Это намного быстрее использовать, но занимает больше времени для создания и расстраивает постоянное поколение.

Сериализация использует их для чтения / записи поля, методы выполнения (readObject, writeObject, readObjectNoData, readResolve) и вызвать несериализуемый базовый класс конструктор (этот последний код не проверяемые).

Похоже, они используются только временно для сериализации / десериализации данного класса объектов. Как указывается в статье, они, вероятно, хранятся с использованием SoftReferences, поэтому убедитесь, что в вашем приложении достаточно памяти, и они будут регенерироваться реже.

Удивительно, но другого решения, похоже, не существует.

...