Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Интересно, если я на собеседовании скажу, что это вредный и опасный костыль, который своим существованием сбивает с толку, то буду прав?
А тем, что теряется однозначность. Мне кажется, что в этом методе можно разве что кеши и временные файлы подчищать, которые не влияют на работу уже по факту.
Иначе если возникает потребность в этом методе, то это баг архитектуры.
Иначе если возникает потребность в этом методе, то это баг архитектуры.
зависит от собеседующего с Вами.
Насколько ячитал Хростманна, finalize() необходим при работе с нативным кодом и освобождения ресурсов там, а исключить вероятность работы Java с С-кодом, например, нельзя. Как Вы решили бы проблему освобождения ресурсов, созданных при работе с не Java-кодом внутри Java -кода?
finalize в Яве нужен, чтобы его не использовать.
У Джошуа Блоха хорошо написано об этом методе: link
Краткая выдержка:
1. finalize() можно использовать только в двух случаях:
1.1. Проверка/подчистка ресурсов с логированием
1.2. При работе с нативным кодом, который не критичен к утечке ресурсов
2. finalize() замедляет работу GC по очистке объекта в 430 раз
3. finalize() может быть не вызван
Собственный опыт — за пять лет ни разу не переопределял finalize(). Собственно, переопределение finalize() — признак smelly кода.
Краткая выдержка:
1. finalize() можно использовать только в двух случаях:
1.1. Проверка/подчистка ресурсов с логированием
1.2. При работе с нативным кодом, который не критичен к утечке ресурсов
2. finalize() замедляет работу GC по очистке объекта в 430 раз
3. finalize() может быть не вызван
Собственный опыт — за пять лет ни разу не переопределял finalize(). Собственно, переопределение finalize() — признак smelly кода.
Исключения, брошенные в методе finalize, не обрабатываются потоком-финализатором, т.е. данный стектрейс скорее всего нельзя будет отследить.Есть такая хорошая штука, называется UncaughtExceptionHandler и его можно проставить потоку, группе потоков или всему приложению — так вы решите проблему всех непойманных эксепшнов.
А смысла нет — это неудачный костыль, который не удаляют из-за совместимости с прошлыми версиями.
Интересно, а почему он тогда до сих пор не deprecated?
Подумавши, родил два варианта:
а) Создатели верят, что этот метод будет еще приносить пользу тем глупцам, которые забывают сами освобождать ресурсы
б) Не красиво, когда в святая-святых — классе Ojbect будет висеть метод @Deprecated
а) Создатели верят, что этот метод будет еще приносить пользу тем глупцам, которые забывают сами освобождать ресурсы
б) Не красиво, когда в святая-святых — классе Ojbect будет висеть метод @Deprecated
Потому что deprecated нужно удалить в течение 2 релизов, а сабж не удалят никогда, даже если он устарел?
Вполне себе нормальная вещь, большинство сборщиков ошибок вешаются на поток как UncaughtExceptionHandler и репортят исключения на сервер.
PhantomReference
Не разу не использовал finalize и не собираюсь. Тот кто не закрываает ресурсы при помощи try-finally сам себе злобный Буратино.
Единственный смысл finalize, который я знаю — последняя линия обороны против чужих ошибок. К примеру, я создаю класс, который использует соединение с каким-то внешним ресурсом (ну, скажем, с базой данных). Предполагается, что использоваться он будет примерно так:
MyClass c = new MyClass();
c.openConnection();
c.doSomething();
c.doSomethingElse();
…
c.doOneMoreThing();
c.closeConnection();
Я не могу гарантировать, что тот, кто будет пользоваться классом, не забудет закрыть соединение. Поэтому, на самый крайний случай, я могу добавить закрытие соединения в finalize в своем классе.
MyClass c = new MyClass();
c.openConnection();
c.doSomething();
c.doSomethingElse();
…
c.doOneMoreThing();
c.closeConnection();
Я не могу гарантировать, что тот, кто будет пользоваться классом, не забудет закрыть соединение. Поэтому, на самый крайний случай, я могу добавить закрытие соединения в finalize в своем классе.
Мне кажется, что это не правильно — усложнять свой код, что бы кто-то подобрать за кем-то. Тогда весь код нужно обвешать if'ами, который прощитывает все остальные невалидные инварианты помимо одного валидного(так называемая защита от дурака).
ИМХО Код должен работать только так, как он должен работать. В остальных случаях он должен либо падать либо работать не правильно. Если пишите либу — нужно писать об этом в Faq/туториале, том же Javadoc. Если человек не умеет/не хочет читать документацию/вики/туториал, то это его проблемы.
Ведь это и так достаточно нетривиальная задача — написать код который просто работает(как бы смешно это не звучало).
ИМХО Код должен работать только так, как он должен работать. В остальных случаях он должен либо падать либо работать не правильно. Если пишите либу — нужно писать об этом в Faq/туториале, том же Javadoc. Если человек не умеет/не хочет читать документацию/вики/туториал, то это его проблемы.
Ведь это и так достаточно нетривиальная задача — написать код который просто работает(как бы смешно это не звучало).
Я всегда стараюсь писать код, который будет работать — хоть как-то — даже если его используют неправильно. В конце концов, задача ведь — сделать, чтоб работало, и позиция «Прокукарекал — а там хоть не рассветай» не очень конструктивна.
Конечно, если код видит, что что-то идёт не так, он должен сообщить об этом. Ну, скажем, сказать" конфигурация не найдена — использую значения по умолчанию". Поэтому в моём примере финализатор, если он обнаружит незакрытое соединение, попробует ещё и записать в лог.
Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват. В моём же примере неправильная работа кода приводит к утечке ресурса, а это ошибка гадкая, трудноуловимая, и на продакшене может попортить немало крови.У меня в своё время был именно такой случай — из-за изменения в логике вкралась ошибка, и иногда управление не попадало на тот кусок, который закрывал соединение с базой. В результате начались падения программы из-за того, что закончились соединения. Происходило это не всегда, в совершенно ином куске программы, и нам потребовалось немало времени на то, чтобы поймать ошибку.
Конечно, если код видит, что что-то идёт не так, он должен сообщить об этом. Ну, скажем, сказать" конфигурация не найдена — использую значения по умолчанию". Поэтому в моём примере финализатор, если он обнаружит незакрытое соединение, попробует ещё и записать в лог.
Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват. В моём же примере неправильная работа кода приводит к утечке ресурса, а это ошибка гадкая, трудноуловимая, и на продакшене может попортить немало крови.У меня в своё время был именно такой случай — из-за изменения в логике вкралась ошибка, и иногда управление не попадало на тот кусок, который закрывал соединение с базой. В результате начались падения программы из-за того, что закончились соединения. Происходило это не всегда, в совершенно ином куске программы, и нам потребовалось немало времени на то, чтобы поймать ошибку.
Моя практика показывает, что код работающий «хоть как-то» именно так и работает «хоть как-то». Вместо того, что бы сообщить явно и потратить пол дня на фиксинг этого бага — на последующий дебаг проблемы тратятся месяцы.
>> Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват.
Я с этим утверждением полностью согласен. Именно поэтому я придерживаюсь философии «Let it crash» — это позволяет узнать о проблеме намного раньше. Не работающий код должен кричать об этом во все горло, а не «тихо неправильно работать».
Вот ведь признайтесь — если код будет работать неправильно на продакшне — как скоро вы об этом узнаете? В случае «exception'a» я думаю к вам сразу прибегут. В случае логирования с уровнем «error» и продолжающей неправильно работать системе — к вам прибегут намного позже.
Так что на мой взгляд бОльшее зло позволять коду работать тихо неправильно.
>> из-за изменения в логике вкралась ошибка
Я понимаю, что такие ошибки очень неприятные, но я подобного типа проблемы стараюсь решать другими путями, если это возможно. Понятно, что есть когда «по-другому вообще никак». Но на самом-то деле если соединения «текут», то соответственно и производительность всей системы тоже падает.
>> Код, работающий неправильно — это плохо, вне зависимости от того, кто в этом виноват.
Я с этим утверждением полностью согласен. Именно поэтому я придерживаюсь философии «Let it crash» — это позволяет узнать о проблеме намного раньше. Не работающий код должен кричать об этом во все горло, а не «тихо неправильно работать».
Вот ведь признайтесь — если код будет работать неправильно на продакшне — как скоро вы об этом узнаете? В случае «exception'a» я думаю к вам сразу прибегут. В случае логирования с уровнем «error» и продолжающей неправильно работать системе — к вам прибегут намного позже.
Так что на мой взгляд бОльшее зло позволять коду работать тихо неправильно.
>> из-за изменения в логике вкралась ошибка
Я понимаю, что такие ошибки очень неприятные, но я подобного типа проблемы стараюсь решать другими путями, если это возможно. Понятно, что есть когда «по-другому вообще никак». Но на самом-то деле если соединения «текут», то соответственно и производительность всей системы тоже падает.
Я с этим утверждением полностью согласен. Именно поэтому я придерживаюсь философии «Let it crash» — это позволяет узнать о проблеме намного раньше. Не работающий код должен кричать об этом во все горло, а не «тихо неправильно работать».
С точки зрения бизнеса такая позиция далеко не всегда оправдана. Ошибки бывают разные. Понятно, что если код, к примеру, тихой сапой портит базу данных, то это никуда не годится. Но вот другой пример (тоже из личной практики): код должен прочитать файл с кучей записей транзакций, провести некие действия и выдать отчёт. В результате некоей неразберихи в какой-то момент на вход пошли файлы, в которых дата была не в том формате. Если бы программа свалилась, мы получили бы возмущённое начальство, бессонную ночь или две, а также всякие корпоративно-политические неприятности. Но программа была написана так, что она не упала, а написала подробный отчёт об ошибках, отправила его по почте, а сама вместо даты взяла текущую. Пользователи посмотрели с утра (программа ночью работала) и сказали: «Ну и ничего страшного. Вот у таких и таких транзакций поменяйте дату на вчерашнюю, а так всё нормально». Днём мы спокойно поправили формат и вопрос был закрыт.
А с логами у меня было так: все ошибки из логов автоматически присылались по почте всеё команде, и непременно разбирались. Так что если бы та библиотека, которой мы пользовались, продиагностировала течь и сообщила об этом, мы бы непременно эту ошибку внесли в план исправлений, и исправили бы достаточно скоро.
С точки зрения бизнеса такая позиция далеко не всегда оправдана. Ошибки бывают разные. Понятно, что если код, к примеру, тихой сапой портит базу данных, то это никуда не годится. Но вот другой пример (тоже из личной практики): код должен прочитать файл с кучей записей транзакций, провести некие действия и выдать отчёт. В результате некоей неразберихи в какой-то момент на вход пошли файлы, в которых дата была не в том формате. Если бы программа свалилась, мы получили бы возмущённое начальство, бессонную ночь или две, а также всякие корпоративно-политические неприятности. Но программа была написана так, что она не упала, а написала подробный отчёт об ошибках, отправила его по почте, а сама вместо даты взяла текущую. Пользователи посмотрели с утра (программа ночью работала) и сказали: «Ну и ничего страшного. Вот у таких и таких транзакций поменяйте дату на вчерашнюю, а так всё нормально». Днём мы спокойно поправили формат и вопрос был закрыт.
А с логами у меня было так: все ошибки из логов автоматически присылались по почте всеё команде, и непременно разбирались. Так что если бы та библиотека, которой мы пользовались, продиагностировала течь и сообщила об этом, мы бы непременно эту ошибку внесли в план исправлений, и исправили бы достаточно скоро.
Факт того, что ваш парсер логов собирает ошибки и отправляет автоматически всем разработчикам на электронную почту — это и есть «кричать во все горло».
Я имел счастье саппортить систему написанную несколькими поколениями разработчиков. И знаете — насмотрелся на «код, который как-то работает». И в долгосрочной перспективе получается система, которая слабо поддается отладке.
Другой пример из моей практикой, схожий с вашим — есть калькулятор финансов, который выдает расчет работнику кредитования о кредитной истории в виде PDF документа. И вот тоже ошибка «логировалась» о том, что часть данных не удается загрузить с внешнего сервиса. Но это успешно проигнорировали. И так проработало пару недель, пока не заметили случайно на продакшне. За этот срок было выдано много кредитов. И неизвестно какой урон понесет фирма после такого в долгосрочной перспективе.
Так что в долгосрочной перспективе для фирмы лучше один раз получить по шапке за оплошность.
Я имел счастье саппортить систему написанную несколькими поколениями разработчиков. И знаете — насмотрелся на «код, который как-то работает». И в долгосрочной перспективе получается система, которая слабо поддается отладке.
Другой пример из моей практикой, схожий с вашим — есть калькулятор финансов, который выдает расчет работнику кредитования о кредитной истории в виде PDF документа. И вот тоже ошибка «логировалась» о том, что часть данных не удается загрузить с внешнего сервиса. Но это успешно проигнорировали. И так проработало пару недель, пока не заметили случайно на продакшне. За этот срок было выдано много кредитов. И неизвестно какой урон понесет фирма после такого в долгосрочной перспективе.
Так что в долгосрочной перспективе для фирмы лучше один раз получить по шапке за оплошность.
«Как-то» не означало «кое-как» :)
Если программа не может корректно сделать то, что должна, она, безусловно, не должна делать это некорректно. Но если программа может продолжить функционирование с уменьшенным функционалом, то, скорее всего, она должна это сделать.
В конце концов, мы не стали бы пользоваться, скажем, автомобилем, который отказывается ехать оттого, что у него перегорела одна фара.
Если программа не может корректно сделать то, что должна, она, безусловно, не должна делать это некорректно. Но если программа может продолжить функционирование с уменьшенным функционалом, то, скорее всего, она должна это сделать.
В конце концов, мы не стали бы пользоваться, скажем, автомобилем, который отказывается ехать оттого, что у него перегорела одна фара.
Да. Но вы согласны, что при неудачном стечении обстоятельств(темная ночь, плохая видимость) эта негорящая фара может привести к аварии и с точки зрения безопасности было бы разумнее поменять фару?
P.S. И пример с кредитованием приведенный выше еще неизвестно как выльется через несколько лет. А все потому, что один из программистов не подумал заранее и позволил продолжить ехать с по его мнению «выключенной фарой», хотя на самом деле это были «сломаные тормоза».
Через несколько лет и системы, возможно, не будет.
Я работал в компании, которая писала ПО для работы с людьми и их деньгами.
Увидел один раз код, который копипастом распространился везде: если по какой-то «счастливой» случайности не нашли клиента по айди — брался первый попавшийся. Снимались деньги или начислялся долг. Вот как надо начальства бояться )))
Возможно такого никогда не произошло. Но заботливый программист это заложил. И коду не один год…
Выживаемость программы — прямо противоположная вещь надежности в большинстве случаев.
Еще нравится, как люди пишут кругом, не задумываясь:
И даже средства улучшения кода в полуавтоматическом режиме такие вещи делают. Ну, вы поняли…
Увидел один раз код, который копипастом распространился везде: если по какой-то «счастливой» случайности не нашли клиента по айди — брался первый попавшийся. Снимались деньги или начислялся долг. Вот как надо начальства бояться )))
Возможно такого никогда не произошло. Но заботливый программист это заложил. И коду не один год…
Выживаемость программы — прямо противоположная вещь надежности в большинстве случаев.
Еще нравится, как люди пишут кругом, не задумываясь:
if (a != null)
{
a.DoSomething();
}
И даже средства улучшения кода в полуавтоматическом режиме такие вещи делают. Ну, вы поняли…
Конечно, согласен, кто ж спорит. И хорошо, если автомобиль мигает по этому поводу лампочкой на панели, пищит, напоминает. Но ездить он всё равно должен.
Это опасное заблуждение, что автомобиль едет. В большинстве случаев. Лучше перебдеть. По умолчанию желательно считать, что если происходит что-либо неожиданное — контроль над программой утерян и она находится в несогласованном состоянии. Поэтому ее работа должна приравниваться к неработе. Причем, дальнейшая ее работа опаснее неработы, т.к. способствует «скрыванию» проблемы и увеличению убытков.
Природа бага такова, что вы, пока не создав тесты, стабильно его повторяющие, не нашли код и не исправили — причину бага не знаете. Не зная причины, вы никак не можете оценить важность бага и его урон.
Еще, в поддержку того, что лучше упасть — хотя гарантии отсутствия багов не будет никогда, если нормально написан код, покрыт тестами, багов на самом деле не очень много. Поэтому чем жестче программа реагирует на «неожиданное поведение», тем быстрее эти баги отловятся. Возможно даже до продакта.
Только в крайне редких случаях можно так делать — ехать дальше. Не хочется о них и напоминать. Бывает, что у вас приложение для какой-то сферы деятельности, а на ГУИ появляются непонятные артефакты или что-то несущественное не прорисовывается. Или действительно обрабатываете данные с мусором и это ожидаемое поведение, и вы логируете предупреждения. Т.е. очень иногда так можно поступать. К сожалению, многие это «иногда» возводят в абсолют.
Природа бага такова, что вы, пока не создав тесты, стабильно его повторяющие, не нашли код и не исправили — причину бага не знаете. Не зная причины, вы никак не можете оценить важность бага и его урон.
Еще, в поддержку того, что лучше упасть — хотя гарантии отсутствия багов не будет никогда, если нормально написан код, покрыт тестами, багов на самом деле не очень много. Поэтому чем жестче программа реагирует на «неожиданное поведение», тем быстрее эти баги отловятся. Возможно даже до продакта.
Только в крайне редких случаях можно так делать — ехать дальше. Не хочется о них и напоминать. Бывает, что у вас приложение для какой-то сферы деятельности, а на ГУИ появляются непонятные артефакты или что-то несущественное не прорисовывается. Или действительно обрабатываете данные с мусором и это ожидаемое поведение, и вы логируете предупреждения. Т.е. очень иногда так можно поступать. К сожалению, многие это «иногда» возводят в абсолют.
Почему-то припомнилось это
От этого технический долг растет. На первое время, когда пилишь прототип, такое сгодится, но потом это становится похоже на «лечение» кариеса обезболивающим.
Ну, в данном случае это скорее не долг, а кредит. Возможность оплатить счёт позже, когда будут деньги :)
Кстати, аналогия на самом деле неплохая: при злоупотреблении такой политикой возможно техническое банкротство. Однако при разумном использовании всё получается очень хорошо. Мы, например, периодически проводили такие релизы с «раздачей долгов», стараясь назначить их на спокойное время.
Кстати, аналогия на самом деле неплохая: при злоупотреблении такой политикой возможно техническое банкротство. Однако при разумном использовании всё получается очень хорошо. Мы, например, периодически проводили такие релизы с «раздачей долгов», стараясь назначить их на спокойное время.
паосер хабра глючит, удалено
паосер хабра глючит, удалено
А мне кажется, что пусть он лучше словит ошибку, чем будет неправильно делать и дальше в полной уверенности, что он все делает красиво и круто.
Я в ветке выше привёл пару иллюстраций того, почему это далеко не всегда так… Для полноты картины поясню, что описываемые ситуации происходили в крупной финансовой компании. Стоимость того, что система упала и не смогла в нужное время выполнить требуемую операцию, там может быть высока. ОЧЕНЬ высока.
Стоимость того, что из-за течи замедляется работа сервера и его, пока не починили, время от времени нужно перезапустить — ничтожна. Стоимость неполного отчёта может тоже быть велика, но она меркнет на фоне стоимости застрявшей ночной обработки данных.
Стоимость того, что из-за течи замедляется работа сервера и его, пока не починили, время от времени нужно перезапустить — ничтожна. Стоимость неполного отчёта может тоже быть велика, но она меркнет на фоне стоимости застрявшей ночной обработки данных.
Тогда пусть на тестовом сервере отключают финализаторы, а включают их только на продакшене.
Я думаю вы согласитесь в том, что тот факт, что вам в финализаторы пришлось логику пихать — это следствие толи низкой внимательности программистов, толи низкой квалификации программиста. В общем это следствие чьей-то ошибки. И это цена, которую пришлось вам заплатить за чью-то лень/неванимателность/тупость.
Это попытка предотвратить нехорошие поледствия чужих ошибок. Да, это так. Но если Вы посмотрите вокруг, то Вы увидите что так построено огромное количество вещей, которые нас окружают. Лифт откроет обратно двери, если кто-то сунул в последний момент внутрь руку; кофемолка не запустится с незакрытой крышкой; предохранитель сработает, если воткнуть в розетку обогреватель на 20 киловатт… Так что ничего странного или необычного в этом нет.
В каментах к подобной статье от меня я упоминал один более-менее вменяемый вариант использования finalize. Если объекты держатся в кэше на weak/soft-ссылках, то проще очистку системных ресурсов запихать в finalize, чем самому возиться с PhantomReference. Впрочем, многим такой пример покажется искусственным.
Использовал finalize, но только лишь для одной цели… когда искал возможные причины утечки памяти, добавлял в finalize логирование. Другого применения для этого метода в реальном проекте не нашел.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я пытался понять смысл метода finalize