Uniformly, methods of the Java Collections Framework (and the Google Collections Library too) never restrict the types of their parameters except when it's necessary to prevent the collection from getting broken.
Все, что вы написали — верно. Но к исходному вопросу отношение имеет слабое.
Я думаю, вы сами понимаете, насколько нецелесообразно выбирать в качестве скалярной операции byteCode инструкцию.
Теоретизирование на тему гипотетических архитектур, специально заточенных на оптимизацию отдельных операций, также считаю не относящимся к исходной задаче.
Константы, конечно, имеют огромное практическое значение, но на ассимптотическую оценку не влияют.
Задачка не сложная, не спорю. Хотя 90% junior-to-middle java developers из тех, кого я собеседовал, не могли написать работающую реализаци задачки на merge двух отсортированных массивов, не говоря уже о красивом коде.
Эта структура данных является массивом. Размер (максимальное количество элементов) фиксирован и задается при создании. Метод get может возвращать как Object так и null, в случае, если по данному индексу не было put c момента создания или с момента вызова clearAll().
И теперь самое важное. Методы get put и clearAll должны гарантированно работать за O(1).
Я почитал ваши комментарии выше. В современных высоконагруженных системах горизонтальная масштабируемость идет перед вертикальной. Ок, ваш сервер на C будет держать 100000 коннекшнов против 20000 на джаве. А что если у вас завтра будет 10кк? И тут уже выплывают совершенно другие узкие места, такие, как взаимодействие с БД, синхронизация и транзакции между разными нодами в кластере. А тут уже необходимо писать максимально простой и высокоуровневый код. И чем больше задач ложится на «стандартные» хорошо протестированные фреймворки, тем лучше.
Я считаю, что система, где с нагрузкой справляется один сервер, не является highload.
Разве? По-моему, synchronized в общем случае работает на порядок шустрее локов из util.concurrent. Я это утверждаю на основе своих личных тестов. Synchronized также меняет имплементацию в зависимости от использования.
Сейчас есть JIT, есть разные реализации GC, некоторые из них параллельные и неблокирующие. В целом можно сказать, что джава сейчас почти не отстает от си в производительности. Можно нагуглить уйму статей на эту тему.
Правда, я не совсем понимаю, что вы имеете в виду в данном случае под конечным автоматом. Насколько я понимаю, реализация простого конечного автомата не требует GC.
Что вы конкретно хотите? Добавление в конец какой структуры? Если очереди, то, например, вот. Вообще, concurrency framework на java предоставляет отличный базис для имплементации подавляющего большинства задач, связанных с многопоточностью.
Кроме того, если душа лежит к message-oriented программированию, то есть несколько реализаций Actors model на джаве.
Из статьи интересно было узнать некоторые вещи о том, как написан майнкрафт. Хотя мораль, которую можно свести к одной фразе, «не пишите однопоточные игровые сервера», несколько тривиальна. Также не понравилось подчеркнуто агрессивное поведение автора в комментариях. Хороший программист это не тот, кто все знает, а тот, кто умеет учиться и воспринимать опыт других людей.
И да, числа, указанные в статье, это ни разу не «highload». Я, например, вообще не вижу проблемы с сохранением чанков на диск, если диск — это, например, кластер кассандры или другой NoSQL key-value storage.
По поводу MAXINT — никто не заставляет использовать int для хранения версии.
Я думаю, вы сами понимаете, насколько нецелесообразно выбирать в качестве скалярной операции byteCode инструкцию.
Теоретизирование на тему гипотетических архитектур, специально заточенных на оптимизацию отдельных операций, также считаю не относящимся к исходной задаче.
Константы, конечно, имеют огромное практическое значение, но на ассимптотическую оценку не влияют.
Нужно придумать реализацию структуру данных со следующим интерфейсом:
Эта структура данных является массивом. Размер (максимальное количество элементов) фиксирован и задается при создании. Метод get может возвращать как Object так и null, в случае, если по данному индексу не было put c момента создания или с момента вызова clearAll().
И теперь самое важное. Методы get put и clearAll должны гарантированно работать за O(1).
Я считаю, что система, где с нагрузкой справляется один сервер, не является highload.
Правда, я не совсем понимаю, что вы имеете в виду в данном случае под конечным автоматом. Насколько я понимаю, реализация простого конечного автомата не требует GC.
Кроме того, если душа лежит к message-oriented программированию, то есть несколько реализаций Actors model на джаве.
И да, числа, указанные в статье, это ни разу не «highload». Я, например, вообще не вижу проблемы с сохранением чанков на диск, если диск — это, например, кластер кассандры или другой NoSQL key-value storage.