|
|
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Корректен ли код? Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. корректен ли код? Если нет, то поможет ли volatile пометить cache ? Просто никогда не думал насчёт того, что если мы видим корректное visibility ссылки на объект - распространяется ли это на те объекты, на которые он ссылается(композирует, аггрегирует)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 19:22 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerкорректен ли код? Не совсем. Чтение может происходит параллельно с записью, что чревато. questionerЕсли нет, то поможет ли volatile пометить cache ? Устал уже что ли? volatile здесь только влияет на ссылку cache. А ссылка эта нигде в коде не меняется. Можно final воткнуть. questionerПросто никогда не думал насчёт того, что если мы видим корректное visibility ссылки на объект - распространяется ли это на те объекты, на которые он ссылается(композирует, аггрегирует)? Нет, не распространяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 19:48 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Blazkowiczquestionerкорректен ли код? Не совсем. Чтение может происходит параллельно с записью, что чревато. Что прочитаем что-то не то? Можно сказать что-то более конкретное, чем непредсказуемое поведение? BlazkowiczУстал уже что ли? volatile здесь только влияет на ссылку cache. А ссылка эта нигде в коде не меняется. Можно final воткнуть. Я понимаю, что final он же volatile. Но конкретно в этом коде это повлияет разве как-то? или только на возможное расширение класса. Ну то есть разве может кто-то увидеть null ссылку на cache ? Правильно ли, что если не использовать другую коллекцию, то можно использовать например ReadWriteLock? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 22:23 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Это не вопрос ли из анкеты в ваканси Java Developer в Яндекс? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 00:47 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
fixxerЭто не вопрос ли из анкеты в ваканси Java Developer в Яндекс? Я слышал кстати уже такую версию. Возможно собеседующий ходил в яндекс когда-то) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 09:56 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
немного перефразирую второй вопрос если мы не используем volatile/final могут ли быть проблемы с видимостью cache ? ведь получается, что мы сетаем его в конструкторе(думаю это эквивалентно текущей записи). а использовать метод мы можем только после того ссылка создалась. Есть на такой случай HB ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 10:30 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questioner, Тут две проблемы. 1. При удачном стечении обстоятельств, после публикации экземпляра наследника можно схватить NPE на том, что cache все еще null, а digest уже вызвали. 2. Недавно пролетал опрос на то, что бывает с HashMap при многопоточном использовании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 11:29 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньевquestioner, Тут две проблемы. 1. При удачном стечении обстоятельств, после публикации экземпляра наследника можно схватить NPE на том, что cache все еще null, а digest уже вызвали. 2. Недавно пролетал опрос на то, что бывает с HashMap при многопоточном использовании. volatile я так понимаю спасёт нас от 1 пункта. по поводу второго мы там ни о чем не договорились, отличного от того, что поведение непредсказуемо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 11:39 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerпо поводу второго мы там ни о чем не договорились, отличного от того, что поведение непредсказуемо А этого достаточно, чтоб так не делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 11:49 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньевquestionerпо поводу второго мы там ни о чем не договорились, отличного от того, что поведение непредсказуемо А этого достаточно, чтоб так не делать. Пусть я собеседую: Ок, разобрались, что лучше использовать CHM, но допустим по каким-то причинам мы этого сделать не можем, как сделать корректным без CHM ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 12:36 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerПравильно ли, что если не использовать другую коллекцию, то можно использовать например ReadWriteLock? Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 12:47 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerесли мы не используем volatile/final могут ли быть проблемы с видимостью cache ? Надо освежить что там в JMM пишут по поводу конструктора и безопасных публикаций. То есть, если у тебя из конструктора, утекает ссылка на объект, да ещё и в другой поток, то он может увидеть null. questionerведь получается, что мы сетаем его в конструкторе(думаю это эквивалентно текущей записи). Да, но вопрос в том, чем ты гарантируешь что другой поток не увидит объект во время выполнения конструктора? questionerа использовать метод мы можем только после того ссылка создалась. Тут чувствуется некоторое непонимание в вопросе. Нет никакого "ссылка создалась". Ссылку на объект можно получить до того как закончит выполнение конструктор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 12:53 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев 1. При удачном стечении обстоятельств, после публикации экземпляра наследника можно схватить NPE на том, что cache все еще null, а digest уже вызвали. Из наследника можно получить null даже если там будет final. Эта другая проблема. Сергей Арсеньев2. Недавно пролетал опрос на то, что бывает с HashMap при многопоточном использовании. Так он же и спрашивал. Теперь решил по второму кругу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 12:55 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
BlazkowiczИз наследника можно получить null даже если там будет final. Эта другая проблема. Не-е, гоню. Это в родительском классе можно получить null в final поле. В любом случае родители и наследники, это не единственный способ сделать публикацию объекта не безопасной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 12:56 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
BlazkowiczquestionerПравильно ли, что если не использовать другую коллекцию, то можно использовать например ReadWriteLock? Да. прошу оценить критическим взглядом: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 13:12 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Blazkowiczquestionerесли мы не используем volatile/final могут ли быть проблемы с видимостью cache ? Надо освежить что там в JMM пишут по поводу конструктора и безопасных публикаций. То есть, если у тебя из конструктора, утекает ссылка на объект, да ещё и в другой поток, то он может увидеть null. В представленном коде не утекает, но тут пишут, что даже утекать не обязательно для проблем Blazkowiczquestionerведь получается, что мы сетаем его в конструкторе(думаю это эквивалентно текущей записи). Да, но вопрос в том, чем ты гарантируешь что другой поток не увидит объект во время выполнения конструктора? А как можно запустить конструирование одного и того же объекта из разных тредов? Я на самом деле не представляю другого способа кроме как утекания ссылки из конструктора. В нашем конкретно коде такое возможно? questionerа использовать метод мы можем только после того ссылка создалась. BlazkowiczТут чувствуется некоторое непонимание в вопросе. Нет никакого "ссылка создалась". Ссылку на объект можно получить до того как закончит выполнение конструктор. Кроме утекания из конструктора ещё есть какие-то варианты такого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 13:23 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
BlazkowiczBlazkowiczИз наследника можно получить null даже если там будет final. Эта другая проблема. Не-е, гоню. Это в родительском классе можно получить null в final поле. В любом случае родители и наследники, это не единственный способ сделать публикацию объекта не безопасной. Надо бы отдельно это обсудить) может ссылку какую выдадите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 13:30 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Blazkowicz В любом случае родители и наследники, это не единственный способ сделать публикацию объекта не безопасной. Наследник был упомянут, токма по причине абстрактности класса. final как бы гарантирует что ссылка на экземпляр раньше времени (заполнения final) не утечет. Другое дело, что HashMap не очень то хороший cache, особенно в свете многопоточности. Есть же всякие в Guave и у Apache реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 14:40 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевBlazkowicz В любом случае родители и наследники, это не единственный способ сделать публикацию объекта не безопасной. Наследник был упомянут, токма по причине абстрактности класса. final как бы гарантирует что ссылка на экземпляр раньше времени (заполнения final) не утечет. Другое дело, что HashMap не очень то хороший cache, особенно в свете многопоточности. Есть же всякие в Guave и у Apache реализации. Приватное поле недоступно наследнику же. Не понял как final с утеканием связан. Может пример? Ну это понятно. что есть нормальные протестированные кеши, это не практический вопрос, исключительно в образовательных целях рассматривается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 15:16 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerНу это понятно. что есть нормальные протестированные кеши, это не практический вопрос, исключительно в образовательных целях рассматривается Чисто в образовательных целях надо читать Java Memory Model. Там есть ссылочка на документик в котором описывается как jvm инициализирует экземпляр класса в каком порядке и когда отпускается блокировочка не позволяющая увидеть ссылку раньше некоторого события. Так вот final поля они до, а не final и цепочка конструкторов после. В связи с чем есть теоретическая возможность (и та скорее всего не для x86) что кто-то увидит ссылку на экземпляр наследника, когда cache еще не до конца проинициализирован. После чего вызов instance.digest(), который у Вас первым делом пытался сделать cache.get() будет слегка удивлен. Если я правильно понимаю (хотя скорее ошибаюсь), то и вызов readLock.lock(); из другого потока (не того, в котором происходила инициализация instance) не устанавливает h-b грань (ибо в нем инициализации то не происходило). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 15:42 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
Usmanquestioner, https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java Это к чему вообще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 16:36 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerЭто к чему вообще?К 1-му посту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 16:38 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
UsmanquestionerЭто к чему вообще?К 1-му посту Если честно, я не понял, проясните. В примере с вики там волатильная ссылка, но там и проверяется на null эта же ссылка, в нашем случае не так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 16:56 |
|
||
|
больше DCL
|
|||
|---|---|---|---|
|
#18+
questionerВ примере с вики там волатильная ссылкаВ Вашем случае переменную cache необходимо сделать volatile questionerно там и проверяется на null эта же ссылка, в нашем случае не такв этом необходимости нет, т.к. cache сразу инициализируется.questionerкорректен ли код?думаю - да, если добавить volatile .questioner Код: java 1. По поводу работы HashMap в мультипоточной среде. (см. Note that this implementation is not synchronized ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 17:12 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39391901&tid=2123206]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 343ms |

| 0 / 0 |
