Невизначена поведінка на Java

Я читав це питання на SO, де обговорюється деяка загальна невизначена поведінка в C ++, і я замислювався: чи Java також має невизначене поведінку?

Якщо це так, то які поширені причини невизначеної поведінки на Java?

Якщо ні, то які функції Java звільняють від такої поведінки, і чому з цими властивостями не були реалізовані останні версії C і C ++?

У Java ви можете вважати поведінку неправильно синхронізованої програми невизначеною.

Java 7 JLS використовує слово "undefined" один раз, у 17.4.8. Виконання та вимоги до причинності :

^{Ми використовуємо f|dдля позначення функції , заданої, обмежуючи область fв d. Для всіх xв d, f|d(x) = f(x)і для всіх, що xне в d, f|d(x)не визначено ...}

Документація Java API вказує деякі випадки, коли результати не визначені - наприклад, у (застарілому) конструкторі Дата (int рік, int місяць, int день) :

^{Результат не визначений, якщо даний аргумент виходить за межі ...}

Javadocs для стану ExecutorService.invokeAll (колекція) :

^{Результати цього методу не визначені, якщо дана колекція буде змінена під час цієї операції ...}

Менш формальний вид "невизначеної" поведінки можна знайти, наприклад, у ConcurrentModificationException , де документи API використовують термін "найкращі зусилля":

^{Зауважте, що невдала поведінка не може бути гарантована, оскільки взагалі неможливо дати будь-які жорсткі гарантії за наявності несинхронізованих одночасних модифікацій. Невдалі операції кидаються ConcurrentModificationExceptionна основі найкращих зусиль . Тому було б неправильно писати програму, яка залежала від цього винятку від її правильності ...}

Додаток

Один із коментарів до питань стосується статті Еріка Ліпперта, яка дає корисне вступ до питань теми: поведінка, визначена реалізацією .

Я рекомендую цю статтю для мовно-агностичних міркувань, хоча варто пам’ятати, що автор націлений на C #, а не на Java.

Традиційно ми говоримо, що ідіома мови програмування має невизначену поведінку, якщо використання цієї ідіоми може мати будь-який ефект; він може працювати так, як ви очікуєте, або він може стерти ваш жорсткий диск або збити вашу машину. Крім того, автор укладача не зобов’язаний попередити вас про невизначену поведінку. (Насправді, є деякі мови, в яких програмам, які використовують ідіоми "невизначеної поведінки", мовна специфікація дозволена збивати компілятор!) ...

Навпаки, ідіома, що має поведінку, визначену реалізацією, - це поведінка, де автор компілятора має кілька варіантів того, як реалізувати функцію, і повинен вибрати її. Як випливає з назви, поведінка, визначена реалізацією, принаймні визначена. Наприклад, C # дозволяє впровадженню викидати виняток або створювати значення, коли ціле ділення переповнюється, але реалізація повинна вибрати один. Він не може стерти ваш жорсткий диск ...

Які є фактори, які змушують комітет з розробки мов залишити певні мовні ідіоми як невизначені чи визначені реалізацією поведінки?

Перший головний фактор: чи існують дві існуючі реалізації мови на ринку, які не погоджуються з поведінкою певної програми? ...

Наступним головним фактором є: чи природно ця функція пропонує багато різних можливостей для впровадження, деякі з яких явно кращі за інші? ...

Третій фактор: чи особливість настільки складна, що детальну інформацію про її точну поведінку було б важко або дорого вказати? ...

Четвертий фактор: чи функція покладає на компілятор високий тягар для аналізу? ...

П’ятий фактор: чи ця функція покладає велике навантаження на середовище виконання? ...

Шостий фактор: чи визначає поведінку, що визначається, виключає якусь велику оптимізацію? ...

Це лише декілька факторів, які приходять на думку; Звичайно, є багато, багато інших чинників, про які обговорюють комітети з мовної розробки, перш ніж зробити функцію "визначеною" або "невизначеною".

_{Зверху - лише дуже коротке висвітлення; повна стаття містить пояснення та приклади до пунктів, зазначених у цьому уривку; це багато читання варто. Наприклад, деталі, наведені для "шостого фактора", можуть дати зрозуміти мотивацію багатьох тверджень у моделі пам'яті Java ( JSR 133 ), що допоможе зрозуміти, чому деякі оптимізації дозволені, що призводить до невизначеної поведінки, а інші заборонені, що призводить до такі обмеження, як вимоги, що відбудуться раніше, та вимоги до причинності .}

_{Жоден із матеріалів статті для мене не є особливо новим, але я буду проклятий, якщо я коли-небудь бачив, як це було представлено настільки елегантним, чітким та зрозумілим способом. Дивовижний.}

Зверху в голові, я не думаю, що в Java є не визначена поведінка, принаймні, не в тому ж сенсі, як у C ++.

Причиною цього є те, що за Java стоїть інша філософія, ніж за C ++. Основна мета дизайну Java полягала в тому, щоб програма могла працювати без змін на платформах, тому специфікація визначає все чітко.

На відміну від цього, основна мета дизайну C і C ++ - це ефективність: не повинно бути ніяких функцій (включаючи незалежність платформи), які б затратили продуктивність, навіть якщо вони вам не потрібні. З цією метою специфікація навмисно не визначає деяку поведінку, оскільки їх визначення спричинить додаткову роботу на деяких платформах і, таким чином, знизить продуктивність навіть для людей, які пишуть програми спеціально для однієї платформи та знають про всі її ідіосинкратії.

Навіть є приклад, коли Java змушена була ввести заднім числом обмежену форму невизначеної поведінки саме з цієї причини: ключове слово строгий FF було введено в Java 1.2, щоб дозволити обчислення з плаваючою комою відхилятися від точно слідування стандарту IEEE 754, як вимагала раніше специфікація , тому що це вимагало додаткової роботи і зробило все обчислення з плаваючою комою повільнішими на деяких загальних процесорах, в той час як насправді дає гірші результати в деяких випадках.

Ява досить намагається винищити невизначену поведінку саме через уроки попередніх мов. Наприклад, змінні рівня класу автоматично ініціалізуються; локальні змінні не автоматично ініціалізуються з міркувань продуктивності, але існує складний аналіз потоку даних, щоб ніхто не написав програму, яка змогла б це виявити. Посилання не є покажчиками, тому недійсні посилання не можуть існувати, і перенаправлення nullвикликає конкретний виняток.

Звичайно, залишаються певні форми поведінки, які не визначені повністю, і ви можете писати ненадійні програми, якщо вважати, що вони є. Наприклад, якщо ви повторюєте звичайні (не сортовані) Set, мова гарантує, що ви побачите кожен елемент точно один раз, але не в тому порядку, коли ви їх побачите. Порядок може бути однаковим у послідовних прогонах або може змінюватися; або він може залишатися таким же, доки не відбудуться інші виділення, або поки ви не оновлюєте JDK тощо. Позбутися від усіх таких ефектів майже неможливо ; наприклад, вам доведеться явно замовляти або рандомізувати всі операції колекцій, і цього просто не варто мати невеликих додаткових неозначених можливостей.

Ви повинні зрозуміти «Невизначене поведінку» та його походження.

Не визначена поведінка означає поведінку, яка не визначена стандартами. C / C ++ має занадто багато різних реалізацій компілятора та додаткових функцій. Ці додаткові функції прив’язували код до компілятора. Це було тому, що не було централізованого розвитку мови. Тож деякі вдосконалені функції деяких компіляторів стали "невизначеними поведінками".

В той час, як у Java мовна специфікація контролюється Sun-Oracle, і ніхто більше не намагається скласти специфікації і, таким чином, не визначено поведінки.

Відредаговано спеціально, відповідаючи на запитання

1. Java не містить визначених форм поведінки, оскільки стандарти були створені перед компіляторами
2. Сучасні компілятори C / C ++ мають більш / менш стандартизовану реалізацію, але функції, реалізовані до стандартизації, як і раніше залишаються позначеними як "невизначена поведінка", оскільки ISO тримає маму з цих аспектів.

Java виключає по суті всю не визначену поведінку, виявлену в C / C ++. (Наприклад: підписане ціле число переповнення, поділ на нуль, неініціалізовані змінні, нульова відмітка покажчика, зміщення більше бітової ширини, подвійне вільне, навіть "немає нового рядка в кінці вихідного коду".) Але у Java є кілька незрозумілих невизначених способів поведінки, які рідко стикаються програмісти.

• Java Native Interface (JNI) - спосіб виклику Java на C або C ++. Існує багато способів виправити JNI, наприклад, помилка підпису функції, здійснення недійсних дзвінків до служб JVM, пошкодження пам’яті, неправильне розподілення / звільнення речей тощо. Я раніше робив ці помилки, і взагалі весь JVM виходить з ладу, коли будь-який один потік, що виконує код JNI, робить помилку.

• Thread.stop(), яка застаріла. Цитата:

  Чому Thread.stopзастаріла?

  Тому що це по своїй суті небезпечно. Якщо зупинити потік, це призведе до розблокування всіх заблокованих моніторів. (Монітори розблоковані, оскільки ThreadDeathвиняток поширює стек.) Якщо будь-який із об'єктів, попередньо захищених цими моніторами, знаходився в непослідовному стані, інші потоки тепер можуть переглядати ці об'єкти в непослідовному стані. Кажуть, такі об'єкти пошкоджені. Коли нитки діють на пошкоджені об'єкти, може виникати довільна поведінка. Така поведінка може бути тонкою і важко виявити, або вона може бути яскраво вираженою. На відміну від інших неперевірених винятків, ThreadDeathмовчки вбиває теми; таким чином, користувач не попереджає, що його програма може бути пошкоджена. Корупція може проявитись у будь-який час після фактичної шкоди, навіть годин чи днів у майбутньому.

  https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html