В части 1 данного введения в методы GC, были подробно рассмотрены различные методы, доступные в последней версии среды выполнения Java-приложений (JRE), разработанной IBM:

• optthruput: Оптимизирует производительность. Это стандартный (default) метод.
• optavgpause: Оптимизирует среднюю длину задержки GC.
• gencon: Использует стиль генеративной синхронизации (generational concurrent) процесса сборки.
• subpool: Ускоряет распределение объектов с очень большими числами для обработки. Этот метод доступен только на машинах IBM с платформами pSeries®и zSeries®, в следствие чего мы не будем обсуждать его далее в нашей статье.

В этой статье мы будем описывать то, как нужно собирать нужную вам информацию, чтобы выбрать тот или иной метод. Большую часть времени, стандартный метод работает без ошибок, и нет необходимости в смене метода. Однако различные методы имеют разные характеристики и разные методы работают более или менее с различными приложениями. Перед тем, как начать оценку методов GC, вам нужно решить, какие именно рабочие характеристики необходимы для того или иного приложения.

Утилизация памяти и качество работы

При выборе метода GC, для вас важно знать, что процесс сборки мусора может воздействовать на производительность по-разному, как положительно, так и отрицательно. Все методы GC, даже синхронизированные, влекут за собой процессы, тормозящие приложения на некоторые промежутки времени. Такие паузы могут вызвать кратковременные задержки в обратной связи и могут уменьшить время, выделенное для работы приложения. Однако, правильно выбранный метод GC может заметно повлиять на улучшение производительности приложения.

Утилизация памяти может повысить качество работы приложения тем, что улучшит локальность объектов и скорость размещения новых объектов. Сборщики мусора, которые перераспределяют объекты в динамической памяти с помощью сжатия или с помощью коллектора перезаписи, перемещают объекты, вызывающие друг друга и расположенные близко друг к другу в динамической памяти, что может существенно повлиять на скорость обработки данных. Сборщики мусора, группирующие объекты, которые вызываются в один момент времени, положительно влияют на качество работы приложений. Коллекторы сжатия и перезаписи также могут повысить скорость распределения новых объектов, оставляя память нефрагментированной. Это исключает необходимость поиска доступной памяти и высматривания области памяти достаточной величины, чтобы продолжать новые распределения.

Очевидно, что для оптимизации качества работы приложения необходимо выбрать метод GC, который минимизирует возможность любого негативного воздействия задержек утилизации памяти. Во-вторых, что менее очевидно, необходимо выбрать тот метод, который обеспечит наибольший положительный эффект от утилизации памяти. Например, если происходит создание большого количества кратковременных объектов, то, выбрав метод gencon, учитывая его преимущество в скорости распределения, можно получить наилучшее качество работы.

В начало

Принимайте во внимание производительность, время откликов и время задержек

Перед тем, как получить наилучшее качество работы приложения, вам необходимо подумать о том, какие именно рабочие характеристики вам нужны. Качество работы приложений может быть описано с помощью двух отличительных особенностей: производительность и время отклика. Производительность представляет собой количество данных, обработанных системой, а время отклика - это то время, которое затрачивает приложение на обработку запросов, считая от времени поступления запроса до завершения процесса обработки. Например, веб-приложение может оперировать 1000 запросами в секунду (производительность) и обрабатывает каждый запрос за 2 секунды (время отклика).

Для некоторых приложений только лишь одна из этих характеристик является важной. Как правило, интерактивному приложению такому, как текстовый редактор, не нужно обрабатывать большие объемы данных, но важно, чтобы оно могло быстро реагировать на нажатие клавиш пользователя. С другой стороны, каждодневная обработка пакетов данных приложением, не должна иметь быстрое время откликов, но необходимо, чтобы оно могло безошибочно обрабатывать большие объемы данных. Однако, большая часть приложений выполняется наилучшим образом, когда у них небольшое время отклика и высокая производительность.

Приложение отвечает на одни запросы быстро, а на другие немного медленнее в зависимости оттого, что еще происходит в момент прихода запроса. Например, если процесс утилизации памяти уже запущен или в очереди на вход скопилось много запросов, то на обработку одного запроса может потребоваться большее количество времени. При решении какие именно рабочие характеристики вы хотите для данного приложения, важно принимать во внимание, как среднее время отклика, так и максимальное время отклика. Например, если интерактивное приложение обычно отвечает на запросы пользователя в течение нескольких миллисекунд (низкое среднее время отклика), но неожиданно задерживается на десять секунд (высокое максимальное время отклика), то, наверняка, пользователям не понравиться такое качество выполнения приложения.

Важно отметить, что время задержки GC не является тем же самым, что и время отклика. Короткие задержки еще не означают быстрое время отклика приложения, и также длинные задержки не обязательно должны вызывать большое время отклика приложения. В очень малонагруженных системах, время задержки является важной частью времени отклика, но по мере увеличения загруженности системы время задержки играет все меньшую роль. Также время задержки более важно в случаях редкой утилизации динамической памяти, чем при частой.

Заметим, что невозможно выработать время отклика приложения с помощью внимательного изучения логов вербализованных GC. Среднее время откликов довольно сильно связаны с производительностью приложения, но не так сильно согласуются со временем задержек GC. Максимальное время отклика всегда больше самой длинной задержки GC, если только загрузка приложения не на исключительно низком уровне. Однако в большей части приложений задержки GC лишь в малой степени влияют на максимальное время задержки, как вы увидите в нашем первом примере.

Использование логов вербализованных GC

Записи вербализованных GC дают возможность проникнуть внутрь работы сборщика мусора, а также могут дать указания на то, какой метод и выбор параметров вам подойдут. Последняя версия комплекта ПО для разработки (Developer Kit) от IBM предоставляет очень подробные логи в формате XML. Эти логи показывают в большой подробности, что именно делал сборщик мусора. Записи вербализованных GC содержат размеры динамической памяти, информацию о разделении динамической памяти в методе gencon, распределение времени задержек, завершенность объектов и очищенные корреляторы. Вы можете активировать вербализованную GC, используя одну из двух опций командной строки: либо -verbose:gc, либо -Xverbosegclog: filename .

Почему необходимо смотреть в логи вербализованных GC?

Существует ряд причин, почему вам может понадобиться активизировать вербализованную GC и внимательно изучать логи. Ваше приложение может находиться в состоянии длительной задержки или периода невозможности отклика, и вам может понадобиться определить причину задержки или вы захотите управлять процессом утилизации памяти. В противном случае, если вы пытаетесь настроить ваше приложения до максимально хорошего его выполнения, то в вербализованном GC могут находиться полезные подсказки, которые помогут в улучшении качества выполнения приложения.

Пример вербализованного GC

Листинг 1 показывает отрезок вербализованного GC одной из сборки в методе optthruput:

                
<af type="tenured" id="1" timestamp="Sun Mar 12 19:12:55 2006" intervalms="0.000">
  <minimum requested_bytes="16" />
  <time exclusiveaccessms="0.025" />
  <tenured freebytes="23592960" totalbytes="471859200" percent="5" >
    <soa freebytes="0" totalbytes="448266240" percent="0" />
    <loa freebytes="23592960" totalbytes="23592960" percent="100" />
  </tenured>
  <gc type="global" id="3" totalid="3" intervalms="11620.259">
    <refs_cleared soft="0" weak="72" phantom="0" />
    <finalization objectsqueued="9" />
    <timesms mark="74.734" sweep="7.611" compact="0.000" total="82.420" />
    <tenured freebytes="409273392" totalbytes="471859200" percent="86" >
      <soa freebytes="385680432" totalbytes="448266240" percent="86" />
      <loa freebytes="23592960" totalbytes="23592960" percent="100" />
    </tenured>
  </gc>
  <tenured freebytes="409272720" totalbytes="471859200" percent="86" >
    <soa freebytes="385679760" totalbytes="448266240" percent="86" />
    <loa freebytes="23592960" totalbytes="23592960" percent="100" />
  </tenured>
  <time totalms="83.227" />
</af>

Открывающий элемент <af> указывает на то, что был запущен процесс сборки, в данном случае: ошибка распределения. В других случаях возможны: <con> для синхронизированной сборки или <sys> для специально запущенной сборки System.gc(). Параллельные сборки случаются только в методах optavgpause или gencon. Специально запускать процесс GC не рекомендуется, поэтому, если в вербализованном GC присутствует элемент <sys>, то используйте возможность переписки кода приложения во избежание помех для процесса утилизации памяти или отмены явной активации утилизации памяти с параметром -Xdisableexplicitgc командной строки.

Заполненность динамической памяти

Элементы, которые больше всего представляют для нас интерес - это три экземпляра элемента <tenured>, описывающие заполненность динамической памяти:

   <tenured freebytes="23592960" totalbytes="471859200" percent="5" >
    <soa freebytes="0" totalbytes="448266240" percent="0" />
    <loa freebytes="23592960" totalbytes="23592960" percent="100" />
  </tenured>

Существует три экземпляра этих элементов, каждый из которых показывает состояние динамической памяти в трех важных моментах времени. Первый экземпляр показывает состояние динамической памяти перед сборкой. Второй экземпляр, вложенный в элемент <gc>, представляет состояние динамической памяти после сборки. Это показывает объем действующих данных в приложении во время процесса сборки. Последний экземпляр показывает объем доступной динамической памяти после выполненного запроса, запускающего процесс распределения. Различие между этим и объемом свободного места, непосредственно доступного после сборки, состоит в том, что его может оказаться больше, чем объема памяти, запрашиваемого в данный момент. Программа управления памятью делит память, выделенную под процессы, на кусочки, чтобы минимизировать возможность "соперничество" при блокировке динамической памяти.

Если заполненность динамической памяти достаточно велика даже после завершения сборки, то максимум динамической памяти может быть слишком мал. Но он может быть увеличен с помощью опции -Xmx в командной строке.

Вложенные элементы <loa> и <soa> описывают динамическую память, используемую под малые и большие области объектов. Большая область объекта является малой областью динамической памяти, выделенной под распределения больших объектов, когда как малые области объектов являются "нормальной" динамической памятью. Первоначально все объекты распределены в малые области объектов, но если малая область заполнена, объекты, которые больше 64KБ располагаются в большие области объектов. Если большая область объектов не запрашивается приложением (означает, что приложение не распределяет никаких больших объектов), то программа управления памятью сокращает большие области объектов до тех пор, пока не освободит всю память для использования ее под "нормальные" распределения.

Следующая строка показывает размер запроса на распределение, который является причиной ошибки распределения:

<minimum requested_bytes="16" />

Если объем доступного свободного места в малой области объектов гораздо больше, чем размер запрашиваемого места, из-за чего запрос не может быть выполнен, то происходит фрагментация динамической памяти. Перед началом работы принимайте во внимание, что у вас может быть очень малый объем динамической памяти или что вы используете метод gencon. Исходная малая динамическая память сокращает процесс фрагментации тем, что побуждает сборщика проводить сжатие раньше, когда динамическая память мала и сжатие менее ресурсоемко. Метод gencon избегает процесса фрагментации с помощью сборщика перезаписи, который эффективно сжимает инкубатор, в качестве побочного действия каждой сборки.

Записи, собранные с помощью метода gencon также имеют строку для инкубатора. Инкубатор - это область динамической памяти, которая содержит все только что размещенные объекты.

<nursery freebytes="0" totalbytes="33554432" percent="0" />

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

Не существует магической формулы для идеального состояния заполненности динамической памяти, но хорошо действует практическое базовое правило, состоящее в том, чтобы размер динамической памяти был в полтора раза больше, чем максимальные потребности системы. Вообщем, чем больше размер динамической памяти, тем лучше качество работы приложения, хотя существуют исключения с определенными системами или некоторыми типами рабочей загруженности. Процесс сокращения динамической памяти также может быть прекращен с помощью добавления опции -Xmaxf=1 в командной строке. Как говорилось ранее, начало работы с малым размером динамической памяти, а затем расширение ее с помощью сборщика мусора, может уменьшить фрагментацию и улучшить качество работы приложения. Таким образом, некоторое количество проб и ошибок требуется для того, чтобы решить, какое из свойств лучше для вашего приложения: стандартная настройка, фиксированный размер динамической памяти, блокировка сжатия или исходно-маленький размер памяти.

Метод gencon работает лучше, когда соблюдает его главное условие -- когда большинство недавно распределенных объектов не будут существовать после большого числа процессов утилизации памяти. Если инкубатор сильно заполнен даже после сборки, слишком много объектов, возможно, остаётся существовать. Обратите внимание на то, что необходимо задавать меньший или больший размер инкубатора таким образом, чтобы процессы сборки происходили в момент, когда в инкубаторе осталось слишком мало действующих объектов. В противном случае переключитесь на другой метод GC.

Сноски и пояснения

Немногословные, ненавязчивые и сквозные сноски могут улучшить характеристики памяти вашего приложения с помощью активации гибкого кэширования. Однако, как и другие вещи, это лучше использовать в меру. Если сборщику приходится вычищать тысячи сносок при каждом процессе сборки, то увеличиваются временные задержки. Подумайте о том, действительно ли вашему приложению необходимо такое количество сносок.

<refs_cleared soft="4" weak="28" phantom="0" />

В отличие от сносок, которые лучше умеренно использовать, пояснения, по существу, бесполезны в хорошо написанном приложении, за тем исключением, когда необходимо убрать исходные источники кода. Если в логах вербализованного GC вы видите, что объекты стоят в очереди для пояснения, попробуйте переписать приложение, чтобы исключить использование пояснителей.

<finalization objectsqueued="5" />

Задержки времени

В логи GC нас также может интересовать информация о времени. Для глобальной сборки анализ времени, выделенного на каждый знак, шаблон и фазы сжатия, пишется в одной из частей элемента <gc>:

<timesms mark="74.734" sweep="7.611" compact="0.000" total="82.420" />

Сжатие - это редкое событие, и по этой причине время сжатия почти всегда равно нулю. Если же случается много сжатий, учтите, что необходимо расширить размер максимальной величины динамической памяти таким образом, чтобы в памяти было больше свободного места, или сократить минимальную величину динамической памяти так, чтобы ресурсоемкость предыдущих сжатий уменьшилась. В противном случае переключитесь на метод gencon. Время развертки должно быть значительно меньше времени разметок. Если время развертки очень долгое, имейте в виду, что необходимо уменьшить размер динамической памяти или переключиться на метод gencon.

Самый последний элемент в каждом элементе коллекции - это элемент <time>, который записывает, сколько времени потребовалось на утилизацию памяти:

<time totalms="83.227" >

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

В начало

Пример 1: Знайте, что вы хотите

В данном примере мы рассматриваем то, как выбор метода утилизации памяти влияет на качество работы с довольно типичным трехуровневым приложением клиент-сервер.

Число активных процессов, которые побуждают приложение работать, дальше увеличивается каждые две минуты. Каждый процесс имеет сопоставимые данные. Таким образом, по мере роста числа процессов, растет и потребление памяти приложением. Приложение запустили на компьютере с четырьмя процессорами, и число активных процессов варьируется от одного до восьми. Как только число процессов становиться больше числа процессоров, процессам приходится соревноваться друг с другом за процессорное время, вследствие чего некоторые из процессов будут постоянно ждать, и качество выполнения приложения ухудшается. Это отражается на снижении продуктивности, более долгим средним временем отклика и гораздо более долгим максимальным временем отклика. Рисунки 1, 2, 3 и 4 показывают графики времени задержек, производительности и времени откликов, когда приложение запущено с методами optthruput и optavgpause. Средняя точка графиков - это точка, в которой система перегружается.

Время задержек

Рисунок 1 показывает время задержек приложения для каждого процесса утилизации памяти с использованием данных о времени в элементах <timesms mark="74.734" sweep="7.611" compact="0.000" total="82.420" /> логи вербализованного GC. Как и ожидалось, задержки optthruput (синяя линяя) гораздо длиннее, чем задержки optavgpause (зеленая линия). Задержки optthruput занимают больше времени по мере роста числа активных данных в динамической памяти, когда как у задержек optavgpause диапазон их колебаний меньше.

Производительность

Рисунок 2 показывает измеренные данные о производительности приложения. Опять же, как и ожидалось, происходит согласование между оптимизацией задержек и оптимизацией производительности: производительность немного выше с использованием метода optthruput (синяя линия), чем производительность с методом optavgpause (зеленая линия), вне зависимости от загрузки приложения. Таким образом, если высокая производительность является для вас самым главным принципом, вам следует использовать метод optthruput вместо метода optavgpause. Метод optthruput имеет большую производительность, чем метод optavgpause для любого приложения, по причине, описанной в Части 2 данного выпуска (см. Ресурсы для ссылки).

Время откликов

Среднее время откликов имеет ту же тенденцию, что и производительность в данном случае. Показатель среднего времени отклика лучше всего в случае использования метода optthruput, как показано на Рисунке 3. Синяя линия изображает метод optthruput, а зеленая линия изображает метод optavgpause. Таким образом, если среднее время откликов для вас является главным принципом, то следует использовать метод optthruput вместо метода optavgpause, даже если среднее время задержек являются меньше с методом optavgpause.

Наконец, Рисунок 4 показывает максимум времени откликов для обоих методов. Синяя линия изображает метод optthruput, а зеленая линия изображает метод optavgpause. Когда система перегружена, максимум времени откликов короче с использованием метода optavgpause. Однако, как только система перегружается, использование метода optthruput выдает более короткое время откликов. Заметим, что максимум времени откликов ближе к размеру времени задержек, когда система недогружена. Время задержек процесса утилизации памяти - наиболее заметные из задержек, на которые могут натыкаться потоки. В этом случае метод optavgpause выдает наилучший максимум времени откликов. С другой стороны, когда система перегружена потокам, приходится ждать другие потоки так же, как и сборщика мусора, вследствие чего максимум времени задержек резко увеличивается для обоих методов. По причине того, что производительность с использованием метода optthruput выше, потоки видят любые последующие потоки в системе, "отходят в сторону" и быстрее ослабляют контроль. И таким образом, максимум времени задержки становиться лучше.

Если система очень сильно загружена или динамическая память меньше, вследствие чего, сборки происходят чаще, метод optthruput может не выдавать ожидаемого хорошего максимума времени откликов. Если сборки мусора происходят очень часто, и совершенно неудачливый поток, который застрял в очереди за другим потоком, также будет ждать нескольких следующих процессов утилизации памяти до тех пор пока не достигнет головы очереди. В таком случае максимальная задержка будет очень долгой с методом optthruput, но гораздо короче с использованием метода optavgpause.

Вывод

Таблицы 1 и 2 изображают сводку времени задержек, времени откликов и производительности для двух методов в случае с легкой загрузкой и случае с перегрузкой:

Как показано в таблицах, если производительность для вас имеет наибольшую важность, вам следует использовать метод optthruput. Если же время отклика более значимо, чем производительность, то ответ на вопрос о выборе метода становится менее очевидным. Когда приложение несильно загружено, то наилучшее время откликов происходит тогда, когда задержки утилизации памяти минимизированы с помощью метода optavgpause. Однако, если число потоков гораздо больше числа процессоров, то приложение перегружается, и в таком случае метод optthruput выдает наилучшее максимальное время отклика. (Другие приложения будут иметь иные признаки состояния перегрузки.)

В любой системе, где процессы стают в очередь, вероятнее всего, время отклика системы будет поглощаться временем очереди, а не задержками утилизации памяти. Многие другие факторы, включая задержки I/O, время ожидания баз данных, время откликов веб-серверов, время ожидания сети и многие другие внешние воздействия также могут влиять на время отклика. По этой причине, время задержек совсем не обязательные индикаторы ожидаемого времени откликов. Степень, при которой время задержек будут влиять на время откликов, также определяется размером динамической памяти и частотой процессов утилизации памяти. Когда динамическая память мала, и утилизация памяти должна происходить очень часто, время задержек имеют больше влияния на время откликов приложения, по сравнению с тем, когда динамическая память довольно больших размеров и сборки происходят гораздо меньше.

В данном примере метод gencon не был проиллюстрирован, потому что для такой рабочей загрузки он выдавал бы гораздо большее время задержек, чем метод optavgpause, а производительность гораздо хуже, чем производительность метода optthruput. Таким образом, для данной рабочей загрузки, метод gencon будет не самым лучшим выбором, вне зависимости от показателей качества работы приложения. Однако, для других случаев рабочей загрузки метод gencon может выдавать очень хорошее сочетание малых временных задержек и высокой производительности. Для рабочей загрузки с очень большими трансакциями метод gencon выдает лучше как время задержек, так и производительность, чем метод optavgpause.

В начало

Пример 2: Получение всего -- иногда -- с методом gencon

Наш второй пример иллюстрирует более сложное приложение с более сложными показателями качества работы. Приложение включает в себя сервер приложения и приложение J2EE, состоящее из нескольких частей и возглавляющее данный сервер. Его запускают с другой машины. Важным требованием к качеству работы приложения является производительность, но также есть и показатель минимального времени отклика. В счетчик производительности включаются только те транзакции, которые завершаются в заданное время, таким образом, показателем качества работы фактически является комбинация показателя производительности и среднего времени отклика.

Время задержек

Рисунок 5 показывает изменения времени задержек для данного примера приложения. Зеленая линия изображает метод gencon, а синяя линия изображает метод optthruput:

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

Всплеск времени задержек в методе gencon происходит, когда хранилище переполняется и требуется несинхронизированная (non-concurrent) сборка всей динамической памяти. Этот процесс сборки происходит медленнее, чем нормальная сборка, но такая сборка происходит очень редко. Работа запущенного приложения длилась 10 или 15 минут. Хранилищу в динамической памяти нет необходимости делать сборку часто и поэтому обычно сборка происходит синхронизировано.

Производительность

Рисунок 6 показывает данные о приложении для двух методов. Метод gencon (зеленая линия) имеет преимущество на 4 процента перед методом optthruput (синяя линия).

Таблица 3 представляет результаты времени задержки и производительность работы приложения. Как видно, метод gencon превосходит метод optthruput по двум показателям. Метод gencon работает лучше по двум причинам. Первая причина, очевидная, состоит в том, что, показатель качества работы учитывает как время отклика, так производительность. Поэтому сочетание хорошей производительности и хорошего времени отклика говорят о том, что метод gencon лучший в данном случае. Вторую же причину сложнее определить. Порядок создания и уничтожения объектов в данном примере приложения выигрывает благодаря отсутствию в методе gencon фрагментации и быстрой сборки редко заполненных инкубаторов. Другие приложения с похожими показателями качества работы, но отличным порядком создания объектов могут работать лучше с использованием метода optthruput.

В начало

Как получить наилучшее качество работы вашего приложения

Первое, что необходимо сделать для оптимизации качества работы вашего приложения - это решить, какие характеристики работы приложения важны для вас. Вы можете выбрать, что именно регулировать, производительность, время откликов или некоторое сочетание того и другого. Как только вы определили свою цель, вы можете начать измерять качество работы вашего приложения, экспериментируя с различными методами, обращаясь за информацией к логам вербализованного GC.

Как было показано на двух примерах, каждое приложение работает по-своему, и вам придется попробовать еще несколько различных свойств пока вы не найдете подходящие размеры динамической памяти, параметры опций и подходящий метод утилизации памяти для наилучшего качества работы вашего приложения и системы.

Мы надеемся, что данная статья и также предыдущая помогли вам лучше понять то, как работает утилизация памяти в IBM SDK. Следующие статьи будут рассматривать другие аспекты Java-технологии, разработанной IBM, включая разделение классов, откладку, мониторинг и возможности профилирования.

Ресурсы

Научиться

• Оригинал статьи: "Java technology, IBM style: Garbage collection policies, Part 2"
  
  
• "Методы утилизации памяти, часть 1," Матиас Персон (developerWorks, май 2006 года): Первая часть из выпуска представляет различные методы GC и рассказывает о их общих характеристиках.
  
  
• Диагностический справочник IBM: Узнайте больше подробностей о вербализованном GC и инструкции по настройке параметров утилизации памяти в разработанной IBM технологии Java. (В формате PDF.)
  
  
• Посетите раздел Java developerWorks: Просмотрите все содержание по языку Java.
  
  
• "Тонкая настройка качества работы утилизации памяти Java," Sumit Chawla (developerWorks, январь 2003 года): Узнайте, как определять и выявлять проблемы утилизации памяти с использованием виртуальной машины Java в реализации IBM.
  
  

Получить продукты и технологии

• Java SDK: Скачайте различные SDK для операционных систем AIX, Linux, и z/OS и другие предлагаемые IBM SDK для Java-технологии с этой страницы.
  
  
• Пакет разработки IBM для Eclipse: Разрабатывайте, тестируйте и работайте с вашими Java-приложениями в удобной среде разработки Java.
  
  
• Микросреда WebSphere Everyplace: Протестированная готовая к работе среда разработки, специально подготовленная для спецификаций J2ME.
  
  
• Пакет разработки IBM для Apache Harmony: Данная среда, разработанная для выполнения кода, создана для проекта Apache Harmony.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Среды выполнения и SDK от IBM: Посетите форум, открытый ведущим выпуска Крисом Бэйли, если хотите задать вопросы, связанные с комплектом средств разработки IBM для Java-платформы.
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Утилизация памяти и качество работы
• Принимайте во внимание производительность, время откликов и время задержек
• Использование логов вербализованных GC
• Пример 1: Знайте, что вы хотите
• Пример 2: Получение всего -- иногда -- с методом gencon
• Как получить наилучшее качество работы вашего приложения
• Ресурсы
• Об авторах
• Комментарии