Вот и я так подумал, что это антонимы, поэтому и спросил в таком ключе :)
А вот с тем что область применения CAP теоремы шире, я на согласен. Ведь, везде говориться что CAP теорема сформулирована именно для распределенных систем.
Как это «всегда доступно», если Вы сами в своем первом комментарии пишете пишите, что «нет доступа к части данных — работа невозможна, все идут на обед.»
Про то что между доступностью и согласованностью можно двигаться в процентах, я абсолютно согласен. Я пытался явно написать в статье, что невозможно полностью (100%) удовлетворить оба случая.
Немного не понял, на что вы намекаете. Можно пожалуйста еще раз? :)
Я утверждаю, что невозможно написать распределенную систему, которая поддерживает в полной мере и Avalability и Consistency. В двух ваших примерах, нет avalability, так как есть промежуток времени, когда некоторые пользователи не могут работать с системой.
Нет доступа к части данных — работа невозможна < — а почему нет? Потому что свич сломался, например, и доступа к данным нет. Т.е. Partion случился. В этом случае вы выбираете CP и жертвуете A (avalability) и идете на обед. Т.е. при случившихся проблемах, вы решаете оставить согласованность, тем что прекращаете работать и отказываетесь от доступности. Это я и хотел описать.
Тут даже вопрос о допустимости немного в другом смысле. А именно в том, случается он или нет. Т.е. жертвовать Partition Tolerance имеется ввиду, разделение системы (читайте отказы компонент) никогда не происходит. Если же это произошло, значит вы уже им не жертвуете а имеете, тогда остается выбрать еще только что-то одно: согласованность или доступность. Вот это для меня самый сложный логический момент, который, я честно говоря не до конца могу сформулировать.
Тест как токовой бесполезно писать. Нужно запукать приложение на копии прода (включая железо и нагрузку) и смотреть с тем и иным подходом. Ну вообще замечание корректное, что самый лучший способ выбрать, это запустить так и так и сравнить. Вопрос больше о том, чтобы бы вы предпочли из теоретических соображений. К сожалению, развернуто опрос провести нельзя: поле текста ограничено 100 символами.
Если вы отдали свое предпочтение одному из подходов или решили, что они идентичны, то рекомендую ознакомиться со моей статьей synchronized vs ReentrantLock. Возможно, вы почерпнете в ней, что-то новое.
Спасибо за статью. Маленький комментарий по поводу workaround для substring. Intern возможно и решит проблему утечки памяти heap, но повальное его использование не по назначению, а ваш пример как раз сюда попадает, может вызвать утечку памяти в PermGen который обычно значительно меньше и вообще не всегда собирается GC.
Вроде на недавно прошедшем JavaOne прямо сказали, что G1 им довести до ума для больших куч так и не удалось. Работает отлично на маленьких хипах, но не более того, так что сильно не обольщайтесь на его счет.
Ничто нигде падать не будет. Просто паузы GC будут занимать значительное время. Ссылки дать не могу. В качестве пруфа сходите как-ниудь на javaone, там каждый раз с этим соглашаются. Мой личный опыт это так же подтверждает.
Если я правильно понял вопрос, и Вы спрашиваете, почему я не упомянул данный подход, то, он не поможет при размере кэша в несколько гигабайт, так как все ваши объекты будут лежать в одном и том же Heap, наряду с объектами которые будут требовать сборки, так что GC надо будет запускаться и сканить всю свою память, что обернется большими паузами.
Обычно анализатором памяти.
Снимпешь heap dump, открываешь и смотришь кто держит объекты, которые по логике вашего приложения уже должны быть собранными. Часто всякие лисенеры держат сильные ссылки на объекты, которые вам больше не нужны.
Можно снять два снепшота с большим интервалом и посмотреть на различия между ними. Только при открывании снепшота, выставите галочку почистить мертвые объекты.
Так же в некоторых анализаторов есть фичи по анализу хипа на подозрения утечек памяти.
А вот с тем что область применения CAP теоремы шире, я на согласен. Ведь, везде говориться что CAP теорема сформулирована именно для распределенных систем.
Я утверждаю, что невозможно написать распределенную систему, которая поддерживает в полной мере и Avalability и Consistency. В двух ваших примерах, нет avalability, так как есть промежуток времени, когда некоторые пользователи не могут работать с системой.
2) При FullGC на стадии compact GC придеться копировать все эти гигабайты.
Снимпешь heap dump, открываешь и смотришь кто держит объекты, которые по логике вашего приложения уже должны быть собранными. Часто всякие лисенеры держат сильные ссылки на объекты, которые вам больше не нужны.
Можно снять два снепшота с большим интервалом и посмотреть на различия между ними. Только при открывании снепшота, выставите галочку почистить мертвые объекты.
Так же в некоторых анализаторов есть фичи по анализу хипа на подозрения утечек памяти.