Как ни крути, но нельзя получить чистого случайного числа (без использования доп. физических девайсов) — почти все они псевдослучайные, а это значит, что если ты знаешь начальный seed — то вся последующая последовательность уже вычислима. На этом и строятся многие фреймворки рандомизированного тестирования — при падении он так же сообщает тебе и начальный seed и что на CI, что локально есть воспроизводимость.
В том и фишка, рандомизированного тестирования, что случайные числа показывают проблемы за рамками ранее описанных кейсов:
самый известный пример — unicode символы, для которых как правило тесты пишутся только latin1 — но когда на вход приходит французский (или любой другой не latin1) — то появляются неожиданные результаты.
После, конечно, добавляют этот кейс, но рандомизированное может показать это значительно раньше, чем их встретишь
Про случайные числа не согласен: как минимум существует randomized testing, которое в итоге имеет бОльшее покрытие. Впрочем там не так, чтобы уж и случайные числа.
Знать о вещи, которая вредная, можно конечно, но спрашивать такое на собеседовании — это полная дичь.
Если человек не знает её, значит поставить человека в неловкое положение, на вопрос потратили время (минимально 5 минут из обычно часа собеседования), у кандидата появится неприятное ощущение того, что его валят — и главный вопрос — зачем? Реальная практическая ценность близка к нулю.
Как по мне, кто начинает разговор о intern как правило сами не знают о чём оно.
Учитывая того как работает String.intern() авторам Jackson были предоставлены доказательства ( Jackson Issue #332 ) того, что не надо использовать этот подход для экономии памяти, вместо этого лучше использовать свой дедупликатор (который контроллируемо может экономить память), но автор оказался упёртым, даже не смотря на предоставление прод профиля.
Вычисленный hashCode по-умолчанию хранится в заголовке объекта и уже не меняется.
Я имел в виду, что никто не запрещает, чтобы это значение было вычислено как адрес объекта, или просто константа (-XX:hashCode=5 кажется)
может или не может — это вопрос второй, в теории никто не запрещает это делать, ведь hash-функция нужна для того, чтобы превращать поиск в hash-структурах из O(N) в O(1).
Но коллизии неизбежны
Когда-то это было так.Теперь, как минимум с 11-ой версии java, это не так.
Как минимум с 9ой исправлен javadoc — и даже в минимум Sun JRE 1.2 hashCode не возвращал адрес объекта. Т.е референс, что когда-то это было так — сомнительный.
hashCode не является адресом объекта, кажется, ещё с версии 1.2. Что изменилось в Java 9 — так это исправили javadoc. Однако даже до этого было сказано, что оно может быть реализовано так, но это не требуется спецификацией. Не стоит выдавать желаемое за действительное.
Однако, при помощи -XX:hashCode=4 можно вернуть желаемое поведение.
Понимаю, что это перевод и в оригинале написана чепуха
This is a native method, which means it will be executed in another language like C, and will return some code regarding the object's memory address.
которую вы и перевели, но по-умолчанию hotspot (как и многие другие) таки возвращают просто псевдослучайное число — можно было бы и указать в пометках переводчика.
Quizlet приложение для телефона:
— многие из нас проводят какое-то время в общественном транспорте, когда можно «потупить» в телефон — или заняться делом, но ноутбук неудобно таскать
— плюс в том, что есть некоторое community вокруг него, где выкладывают словари для книг, курсов и т.п.
Никто не говорить о том, что переписать всё на kotlin/scala/whatever. Я говорю о том, что если в 2019 начинать что-то писать — то вряд ли стоит выбирать Lombok.
Пожалуй та же беда, что и с другими annotation processor-ами времени компиляции:
Если вдруг приходиться отладкой заниматься — с ломбоком начинает напоминать ад (хотя может сейчас уже плагины стали получше). Не совсем очевидно, что там он за код нагенерировал (прежде всего equals/hashcode).
Т.е если говорить о синтаксическом сахаре лет 10 назад — то ломбок был вполне себе ответом, но сейчас, когда есть лучшие решения… зачем делать такой шаг назад?
На мой скромный взгляд, ломбок — как костыль сбоку — если уж добавлять вкусняшек, но при этом оставаясь в java экосистеме — то стоит смотреть больше в сторону kotlin. IMHO.
Как ни крути, но нельзя получить чистого случайного числа (без использования доп. физических девайсов) — почти все они псевдослучайные, а это значит, что если ты знаешь начальный seed — то вся последующая последовательность уже вычислима. На этом и строятся многие фреймворки рандомизированного тестирования — при падении он так же сообщает тебе и начальный seed и что на CI, что локально есть воспроизводимость.
В том и фишка, рандомизированного тестирования, что случайные числа показывают проблемы за рамками ранее описанных кейсов:
самый известный пример — unicode символы, для которых как правило тесты пишутся только latin1 — но когда на вход приходит французский (или любой другой не latin1) — то появляются неожиданные результаты.
После, конечно, добавляют этот кейс, но рандомизированное может показать это значительно раньше, чем их встретишь
Про случайные числа не согласен: как минимум существует randomized testing, которое в итоге имеет бОльшее покрытие. Впрочем там не так, чтобы уж и случайные числа.
Знать о вещи, которая вредная, можно конечно, но спрашивать такое на собеседовании — это полная дичь.
Если человек не знает её, значит поставить человека в неловкое положение, на вопрос потратили время (минимально 5 минут из обычно часа собеседования), у кандидата появится неприятное ощущение того, что его валят — и главный вопрос — зачем? Реальная практическая ценность близка к нулю.
Как по мне, кто начинает разговор о intern как правило сами не знают о чём оно.
Учитывая того как работает String.intern() авторам Jackson были предоставлены доказательства ( Jackson Issue #332 ) того, что не надо использовать этот подход для экономии памяти, вместо этого лучше использовать свой дедупликатор (который контроллируемо может экономить память), но автор оказался упёртым, даже не смотря на предоставление прод профиля.
Читать https://shipilev.net/jvm/anatomy-quarks/10-string-intern/
Вы точно понимаете, что знаете как устроен String.intern() внутри ?
Используете
String.intern()? Спасибо, до свидания.Вычисленный hashCode по-умолчанию хранится в заголовке объекта и уже не меняется.
Я имел в виду, что никто не запрещает, чтобы это значение было вычислено как адрес объекта, или просто константа (
-XX:hashCode=5кажется)может или не может — это вопрос второй, в теории никто не запрещает это делать, ведь hash-функция нужна для того, чтобы превращать поиск в hash-структурах из O(N) в O(1).
Но коллизии неизбежны
Как минимум с 9ой исправлен javadoc — и даже в минимум Sun JRE 1.2 hashCode не возвращал адрес объекта. Т.е референс, что когда-то это было так — сомнительный.
hashCode не является адресом объекта, кажется, ещё с версии 1.2. Что изменилось в Java 9 — так это исправили javadoc. Однако даже до этого было сказано, что оно может быть реализовано так, но это не требуется спецификацией. Не стоит выдавать желаемое за действительное.
Однако, при помощи
-XX:hashCode=4можно вернуть желаемое поведение.Понимаю, что это перевод и в оригинале написана чепуха
которую вы и перевели, но по-умолчанию hotspot (как и многие другие) таки возвращают просто псевдослучайное число — можно было бы и указать в пометках переводчика.
— многие из нас проводят какое-то время в общественном транспорте, когда можно «потупить» в телефон — или заняться делом, но ноутбук неудобно таскать
— плюс в том, что есть некоторое community вокруг него, где выкладывают словари для книг, курсов и т.п.
И конечно не ограничивается только английским.
И про Rust вы наверно пошутили…
Если вдруг приходиться отладкой заниматься — с ломбоком начинает напоминать ад (хотя может сейчас уже плагины стали получше). Не совсем очевидно, что там он за код нагенерировал (прежде всего equals/hashcode).
Т.е если говорить о синтаксическом сахаре лет 10 назад — то ломбок был вполне себе ответом, но сейчас, когда есть лучшие решения… зачем делать такой шаг назад?
это называется вглубь.
Как раз таки наоборот — такой лаконичный способ и безопасный, и не требует особой обработки в отличии от