Банк рефератов содержит более 364 тысяч рефератов, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам: истории, психологии, экономике, менеджменту, философии, праву, экологии. А также изложения, сочинения по литературе, отчеты по практике, топики по английскому.
Полнотекстовый поиск
Всего работ:
364150
Теги названий
Разделы
Авиация и космонавтика (304)
Административное право (123)
Арбитражный процесс (23)
Архитектура (113)
Астрология (4)
Астрономия (4814)
Банковское дело (5227)
Безопасность жизнедеятельности (2616)
Биографии (3423)
Биология (4214)
Биология и химия (1518)
Биржевое дело (68)
Ботаника и сельское хоз-во (2836)
Бухгалтерский учет и аудит (8269)
Валютные отношения (50)
Ветеринария (50)
Военная кафедра (762)
ГДЗ (2)
География (5275)
Геодезия (30)
Геология (1222)
Геополитика (43)
Государство и право (20403)
Гражданское право и процесс (465)
Делопроизводство (19)
Деньги и кредит (108)
ЕГЭ (173)
Естествознание (96)
Журналистика (899)
ЗНО (54)
Зоология (34)
Издательское дело и полиграфия (476)
Инвестиции (106)
Иностранный язык (62792)
Информатика (3562)
Информатика, программирование (6444)
Исторические личности (2165)
История (21320)
История техники (766)
Кибернетика (64)
Коммуникации и связь (3145)
Компьютерные науки (60)
Косметология (17)
Краеведение и этнография (588)
Краткое содержание произведений (1000)
Криминалистика (106)
Криминология (48)
Криптология (3)
Кулинария (1167)
Культура и искусство (8485)
Культурология (537)
Литература : зарубежная (2044)
Литература и русский язык (11657)
Логика (532)
Логистика (21)
Маркетинг (7985)
Математика (3721)
Медицина, здоровье (10549)
Медицинские науки (88)
Международное публичное право (58)
Международное частное право (36)
Международные отношения (2257)
Менеджмент (12491)
Металлургия (91)
Москвоведение (797)
Музыка (1338)
Муниципальное право (24)
Налоги, налогообложение (214)
Наука и техника (1141)
Начертательная геометрия (3)
Оккультизм и уфология (8)
Остальные рефераты (21697)
Педагогика (7850)
Политология (3801)
Право (682)
Право, юриспруденция (2881)
Предпринимательство (475)
Прикладные науки (1)
Промышленность, производство (7100)
Психология (8694)
психология, педагогика (4121)
Радиоэлектроника (443)
Реклама (952)
Религия и мифология (2967)
Риторика (23)
Сексология (748)
Социология (4876)
Статистика (95)
Страхование (107)
Строительные науки (7)
Строительство (2004)
Схемотехника (15)
Таможенная система (663)
Теория государства и права (240)
Теория организации (39)
Теплотехника (25)
Технология (624)
Товароведение (16)
Транспорт (2652)
Трудовое право (136)
Туризм (90)
Уголовное право и процесс (406)
Управление (95)
Управленческие науки (24)
Физика (3463)
Физкультура и спорт (4482)
Философия (7216)
Финансовые науки (4592)
Финансы (5386)
Фотография (3)
Химия (2244)
Хозяйственное право (23)
Цифровые устройства (29)
Экологическое право (35)
Экология (4517)
Экономика (20645)
Экономико-математическое моделирование (666)
Экономическая география (119)
Экономическая теория (2573)
Этика (889)
Юриспруденция (288)
Языковедение (148)
Языкознание, филология (1140)

Реферат: Java: Управление ресурсами

Название: Java: Управление ресурсами
Раздел: Рефераты по информатике, программированию
Тип: реферат Добавлен 18:51:43 10 марта 2005 Похожие работы
Просмотров: 179 Комментариев: 2 Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать

.

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

Что может, а чего не может GC.

Одним из особенностей языка Java является автоматическая сборка мусора - пресловутый Garbage Collector (сокращённо - GC). GC - это фоновый процесс, который занимается поиском и освобождением неиспользуемых объектов. Много копий было сломано в дискуссиях, хорошо это или плохо, причём существенные аргументы есть как у сторонников, так и у противников этой технологии. Но я не об этом. Примем существование GC как данность и рассмотрим особенности программирования в данной среде.

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

Другим следствием является необходимость следить за ссылками на объекты, потому как GC именно по наличию ссылки на объект определяет его нужность. Для возможности управления строгостью ссылок в JDK 1.2 был введён новый пакет java.lang.ref, классы которого позволяет создавать так называемые "слабые" ссылки на объекты. Это особенно полезно для реализации кэширования объектов.

Начитавшись рекламных статей, может показаться, что очисткой ресурсов вообще не стоит заниматься - всё сделает GC. Тут важно понимать, что в понятие ресурсов входит не только оперативная память, но так же и многое другое. Например - открытые файлы, сокеты, ResultSet-ы и Statement-ы в JDBC, и т.д. С очисткой памяти GC в последних JVM справляется довольно неплохо, но вот освобождение других ресурсов, как правило, нельзя делать асинхронно. В противном случае легко получить так называемые "плавающие" ошибки, которые то появляются, то исчезают.

Над разработкой алгоритма работы GC довольно долго корпели разработчики, так что иногда его поведение может показаться несколько странным. В частности, он может освобождать объекты в произвольном порядке, никак не связанном с порядком их создания или очистки последних ссылок на них. Так же, для примера, в JDK 1.3, GC начинает освобождать объекты только тогда, когда текущий пул памяти заполняется. При этом одновременно, этот пул расширяется, пока не дойдёт до заданного верхнего лимита. Одновременно учитывается время последнего доступа и размер объекта. И т.д. и т.п.

По умолчанию верхний лимит пула зависит от системы. В JDK 1.3 он равен 64 мегабайтам. В некоторых случаях лучше снизить эту планку, особенно когда на машине памяти не очень много - тем самым программа быстрей дойдёт до этого лимита и начнёт использовать память повторно.

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

Деструкторов нет. А что вместо?

Многие программисты (особенно только что пересевшие с C++), видят замену деструкторов в виде методов finalize. Это не есть правильно. Во первых, этот метод не вызовется, пока на объект имеются ссылки. Нет гарантии, что он вызовется тогда, когда вам это нужно. Он может вообще никогда не вызваться. Есть, конечно, метод System.runFinalizersOnExit(), но он уже давно deprecated из-за возможных deadlock-ов. Как справедливо заметил Bruce Eckel в замечательной книжке Thinking in Java метод finalize стоит использовать только для того, чтобы освободить память (или другой, не очень критичный ресурс), выделенную в native методах. Для прочих же ресурсов следует добавить явный вызов метода очистки ресурсов (он может называться по-разному - close, dispose, cleanup, и т.д.), внутри конструкции finally. Внутри finally - для того, чтобы не прозевать какое-нибудь исключение. Пример типичных конструкций:

OutputStream out = new FileOutputStream(...);

try

{

...

}

finally { out.close(); }

PreparedStatement stmt = ...;

try

{

stmt.setInt(1,...);

ResultSet rs = stmt.executeQuery();

try

{

...

}

finally { rs.close(); }

}

finally { stmt.close(); }

Если Вы будете писать программы в таком стиле, то многие проблемы обойдут Вас стороной - поверьте, я уже наступал на эти грабли. :-)

Memory Leak в Java и как с ним бороться.

Казалось бы - какие могут быть Memory Leak (утечки памяти), когда есть GC. Но, тем не менее, они возможны. Эти утечки отличаются по своему происхождению от утечек в C/C++ (таких в Java вообще быть не может, за исключением возможных ошибок в JVM, но этот вариант мы здесь не рассматриваем). Они возникают из-за забытых ссылок.

Например - в GUI часто используется механизм слушателей (Listener-ов). Это когда один объект регистрируется в другом объекте для обратного вызова по наступлению какого-нибудь события. Проблема тут может быть одна - если Вы забудете разрегистрировать объект, когда он становится ненужным. При этом он останется болтаться в списке, ну и GC, разумеется, не будет удалять этот объект, пока не придёт время удалить объект со списком (а этого может и не случиться до завершения программы).

В результате - список будет пухнуть, пухнуть, программа работает всё медленней и медленней, и, в конце концов, вылетает OutOfMemoryError.

Отследить такой сценарий можно при помощи специальных программ - профайлеров. Самые известные на данный момент - JProbe и OptimizeIt.

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

Кэширование объектов.

Кэширование объектов применяется для повышения производительности. Когда объект меняется редко (или вообще не меняется в процессе работы программы), то часто полезно прочитать его один раз, и запомнить на него ссылку. Но ссылка - это противоречие между алгоритмом работы GC, а значит, этот объект никогда не будет собран GC (даже если он больше не нужен). Иногда это большого значения не имеет (памяти много, или все объекты требуются очень часто), но чаще желательно всё-таки иметь возможность почистить неиспользуемые объекты.

В JDK 1.2 для этих целей были добавлены несколько классов, самые интересные из них - WeakReference и SoftReference. Weak ("слабая") ссылка будет очищена, если на объект нет более "сильных" ссылок и объект попался под руку GC. Soft ("мягкая") ссылка будет очищена, если на объект нет обычных ссылок, и, к объекту не доступались по этой ссылке определённое время (эвристически рассчитываемое в зависимости от текущего окружения). Для кэширования лучше всего подходят ссылки типа Soft, т.к. в них учитывается частота обращения к объекту.

Непосредственно пользоваться этими ссылками не очень удобно, лучше написать контейнер с их использованием. Вот, например реализация класса SoftHashtable:

import java.lang.ref.SoftReference;

import java.util.Hashtable;

public class SoftHashtable extends Hashtable

{

public SoftHashtable() {}

public Object put(Object key,Object obj)

{

SoftReference ref = (SoftReference)super.put(key,new SoftReference(obj));

if( ref==null ) return null;

return ref.get();

}

public Object get(Object key)

{

SoftReference ref = (SoftReference)super.get(key);

if( ref==null ) return null;

return ref.get();

}

public Object remove(Object key)

{

SoftReference ref = (SoftReference)super.remove(key);

if( ref==null ) return null;

return ref.get();

}

}

Этот класс является неполным, при желании Вы можете перекрыть остальные методы Hashtable. С помощью этого класса Вы уже можете легко организовать свой кэш объектов:

private static Hashtable objCache = new SoftHashtable();

public SuperObject getObject(String key)

{

SuperObject o = (SuperObject)objCache.get(key);

if( o==null )

{

o = loadObject(key);

objCache.put(key,o);

}

return o;

}

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

Оценить/Добавить комментарий
Имя
Оценка
Комментарии:
Где скачать еще рефератов? Здесь: letsdoit777.blogspot.com
Евгений21:43:30 18 марта 2016
Кто еще хочет зарабатывать от 9000 рублей в день "Чистых Денег"? Узнайте как: business1777.blogspot.com ! Cпециально для студентов!
09:02:23 24 ноября 2015

Работы, похожие на Реферат: Java: Управление ресурсами

Назад
Меню
Главная
Рефераты
Благодарности
Опрос
Станете ли вы заказывать работу за деньги, если не найдете ее в Интернете?

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



Результаты(150741)
Комментарии (1839)
Copyright © 2005-2016 BestReferat.ru bestreferat@mail.ru       реклама на сайте

Рейтинг@Mail.ru