Эффективная связь между объектами Java

Question

Я разрабатываю среду для создания эффективных приложений любого размера. Приложения состоят из модулей (приложение также является модулем), и производительность важна для меня. Я знаю, что существуют существующие рамки для модуляции и т. Д., Но мне нужно реализовать свои собственные. Хотя я чрезмерно думал о производительности отдельных модулей и оптимизировал их, связь между объектами (и между потоками) - это то, что я не могу решить, как реализовать. Вот некоторые варианты я Рассмотренные:

• NIO Трубы
• События (регистрирующие слушателей)
• очереди транзакций в контексте приложения

Мой вопрос, Какой из них лучше избегая узких мест и замков? Или есть альтернатива, которую вы можете посоветовать?

Answer 1

Если это проект, который призван привести к кодексу качества продукции, я настоятельно рекомендую вам не реализовать свою собственную инфраструктуру.

Во-первых, очевидно, что вы действительно недостаточно знаете о том, что требует ваше приложение от фреймворка или различных технологий, которые вы можете использовать для реализации такой структуры. Не стоит недооценивать недостаток знаний и риски, связанные с проведением проекта, когда вы не знаете, что делаете, когда начинаете.

Во-вторых, ваша мотивация для реализации вашей собственной структуры неверна. Если вы обнаружите, что существующая структура слишком большая и сложная для ваших нужд, либо выберите более простую структуру, либо просто изучите подмножество, которое вам нужно выполнить, и игнорируйте остальные.

В-третьих, это много работы по проектированию и строительству даже полупристойного каркаса. Вероятно, вам стоит потратить время на создание своего приложения. Конечно, это весело, но ваш босс, вероятно, больше заинтересован в результатах.

В-четвертых, не стоит недооценивать внутренние преимущества использования рамки, которую используют многие другие люди; например сообщество, чтобы задавать вопросы (например, на SO), сообщество для улучшения структуры, трудоустраиваемых людей с рамками их резюме.

Наконец, реализуя свою собственную инфраструктуру, вы, скорее всего, создаете много дополнительных будущих работ по техническому обслуживанию команды/компании. Вы ошибаетесь, и ваши коллеги будут проклинать вас в коридорах в течение следующих 10 лет. Даже если вы получаете право на 100% прав, кто-то из вашей организации все равно должен поддерживать его на всю жизнь приложений, зависящих от него.

Answer 2

Есть слишком много переменных. Единственный способ узнать, будет ли код вашей системы обмена сообщениями таким образом, чтобы он был подключаемым, чтобы вы могли писать его по-разному и оценивать по мере кода.

Жаль, что вы выбросили с помощью фреймворков, большинство из них были бы значительно быстрее, полнее и удобнее, чем все, что вы могли бы написать сами. Тот, кто придумал это требование, должен быть встречен и, возможно, уволен.

Answer 3

i am developing a framework for creating efficient applications in all sizes 

Чтобы дать очень общий совет, который я хотел бы предложить вам погрузиться в исходный код JBoss, чтобы получить представление, как вещи сделаны, когда они должны работать (возможно, самую старую версию вы можете получить, как запуск точка)

Answer 4

Мое единственное, что мы посоветуем, не идет так. Как уже сказал Билл К, большинство реализаций будут значительно быстрее и полнее. Еще важнее то, что есть отличные ресурсы для достижения того, что вы пытаетесь сделать: OSGi, например, с Eclipse и Glassfish v3 под своим поясом.

Лично я реализовал нечто похожее на ваше описание, загружая плагины во время выполнения без необходимости перезапуска контейнера. Это был кошмар для поддержания и отладки. И что более важно, хотя для меня было относительно легко реализовать новые модули (в конце концов, я разработал эту вещь), было очень сложно программировать. В конце концов я много узнал о загрузчиках классов, но все.