2013-05-23 2 views
2

Для печати ГХ журналов веб-приложения, перед запуском TOMCAT, добавьте следующие параметры:Как класс sun.reflect.GeneratedSerializationConstructorAccessor генерируется

-Xms256m 
-Xmx512m 
-XX:PermSize=128M 
-XX:MaxPermSize=512M 
-Xloggc:D:/TomcatGc.log 

Однако следующая информация печатается на Терминал постоянно.

[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor339] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor336] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor341] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor342] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor340] 

Мои вопросы:

  1. Почему эти классы генерируются? Я хотел бы понять эту концепцию , но не могу найти никакой информации об этом.

  2. Как я могу предотвратить выгрузку GC?

ответ

4

это происходит потому, что (может быть, вы используете отражение в вашем приложении) кучи бежит из космоса и GC пытается освободить память выгружать неиспользуемые объекты, поэтому вы видите Unloading class sun.reflect.GeneratedSerializationConstructorAccessor

Подробнее -->http://coding.derkeiler.com/Archive/Java/comp.lang.java.programmer/2006-11/msg00122.html

+0

Спасибо за Youre answer.But У меня есть еще один question.If ** куча бежит из космоса **, Почему не JVM бросает ** OutOfMemoryError: Явное пространство Java ** Исключение. – Felix

+1

@Felix Он выкинет OutOfMemoryError, но сначала он попытается очистить кучу, удалив неиспользуемый объект, если весь объект находится в куче, и GC не может найти свободное пространство для новых объектов. Тогда ** он действительно выбросит OutOfMemoryError ** –

+0

Еще раз спасибо за ваш ответ. – Felix

2

Ваш первый вопрос был дан ответ @pXL, но:

  1. How can I prevent the GC unloading them?

Вы не можете. Зачем ты хочешь? Они больше не ссылаются, что подразумевает отсутствие доступных экземпляров, поэтому они имеют право на сбор мусора, поэтому они собираются с мусором, что подразумевает разгрузку.

Предотвращение этого было бы бессмысленным и контрпродуктивным.

+0

Спасибо за ваш ответ. Я признал, что сделал глупую ошибку. – Felix

2

Различные типы аксессоров

Метод аксессоры и конструктор аксессорах либо нативные или генерируются. Это означает, что мы используем NativeMethodAccessorImpl или GeneratedMethodAccessor для методов и NativeConstructorAccessorImpl и GeneratedConstructorAccessor для конструкторов. Аксессор будет нативный или генерируется и контролируется и решается двумя системными свойствами:

  1. sun.reflect.noInflation = ложно (значение по умолчанию является ложным)
  2. sun.reflect.inflationThreshold = 15 (по умолчанию значение равно 15)

Когда sun.reflect.noInflation установлено значение истинно, то всегда будет сгенерирован аксессор используется, и нет никакого смысла для свойств системы sun.reflect.inflationThreshold. Когда sun.reflect.noInflation имеет значение false и значение sun.reflect.inflationThreshold установлено равным 15 (это поведение по умолчанию, если оно не указано), то это означает, что для первых 15 обращений к конструктору (или методам) собственный генератор будет и после этого для использования будет предоставлен сгенерированный аксессуар (из ReflectionFactory).

Собственный аксессор использует собственные вызовы для доступа к информации, тогда как сгенерированный аксессор - это все байтовый код и, следовательно, очень быстрый.С другой стороны, генерируемому аксессуру требуется время для создания экземпляра и загрузки (в основном раздувается и, следовательно, системные свойства, контролирующие его, имеют имена, включая слово «инфляция»).

Более подробную информацию можно найти в оригинальной blog

Смежные вопросы