Communication efficace entre les objets Java

Question

Je suis en train de développer un framework pour créer des applications efficaces dans toutes les tailles. Les applications sont constituées de modules (l'application est également un module) et la performance est importante pour moi. Je sais qu'il existe des cadres pour la modularisation, etc., mais j'avais besoin de mettre en place le mien. Bien que je ai surestimé la performance des modules individuels et les optimisé, la communication entre les objets (et entre les threads) est quelque chose que je ne peux pas décider comment mettre en œuvre. Voici les quelques options je considérais:

• Pipes NIO
• événements (enregistrement auditeurs)
• files d'attente de transaction dans le contexte de l'application

Ma question est, Lequel d'entre eux est mieux éviter les goulots d'étranglement et les verrous? Ou y a-t-il une alternative que vous pouvez conseiller?

Answer 1

S'il s'agit d'un projet destiné à générer du code de qualité de production, je vous conseille fortement de ne pas mettre en œuvre votre propre infrastructure. pas Tout d'abord, il est évident que vous ne savez pas vraiment ce que votre application nécessite d'un framework, ou les différentes technologies que vous pouvez utiliser pour implémenter un tel framework. Ne sous-estimez pas votre manque de connaissance, et les risques d'entreprendre un projet où vous ne savez pas ce que vous faites quand vous commencez. Deuxièmement, votre motivation pour mettre en œuvre votre propre cadre est fausse. Si vous trouvez un cadre existant trop grand et compliqué pour vos besoins, choisissez un cadre plus simple ou apprenez simplement le sous-ensemble dont vous avez besoin pour faire votre travail ... et ignorez le reste. Troisièmement, il faut beaucoup de travail pour concevoir et construire même un cadre à moitié décent. C'est probablement le temps que vous devriez consacrer à la construction de votre application. Bien sûr, c'est amusant, mais votre patron est probablement plus intéressé par les résultats.Quatrièmement, ne sous-estimez pas les avantages intrinsèques de l'utilisation d'un cadre que beaucoup d'autres personnes utilisent; par exemple. une communauté à poser des questions de (comme sur SO), une communauté pour améliorer le cadre, des personnes employables avec le cadre sur leur CV. Enfin, en mettant en œuvre votre propre cadre, vous allez probablement créer beaucoup de travaux de maintenance supplémentaires pour l'équipe/la société. Vous vous trompez et vos collègues vont vous maudire dans les couloirs pour les 10 prochaines années. Même si vous avez 100% le bon cadre, quelqu'un dans votre organisation doit le maintenir pour la durée de vie des applications qui en dépendent.

Answer 2

Il y a beaucoup trop de variables. La seule façon de savoir sera de coder votre système de messagerie de manière à pouvoir l'écrire de différentes manières et de le mesurer au fur et à mesure que vous codez.

Pitié que vous avez jeté à l'aide de cadres, la plupart serait nettement plus rapide, plus complète et plus facile à utiliser que tout ce que vous pourriez écrire vous-même. Quiconque a proposé cette exigence devrait être confronté et peut-être renvoyé.

Answer 3

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

Pour donner un avis très général, je vous suggère de plonger dans le code source de jboss pour obtenir une impression comment les choses sont faites quand ils sont censés travailler (peut-être la plus ancienne version que vous pouvez obtenir, comme départ point)

Answer 4

Mon seul conseil serait de ne pas aller de cette façon. Comme l'a déjà dit Bill K, la plupart des implémentations seraient beaucoup plus rapides et plus complètes. Plus important encore, il existe d'excellentes ressources pour réaliser ce que vous essayez de faire: OSGi par exemple, qui a Eclipse et Glassfish v3 à son actif.

Personnellement, je mis en œuvre quelque chose de similaire à votre description, chargement des plugins lors de l'exécution sans avoir besoin de redémarrer le conteneur. C'était un cauchemar à maintenir et à déboguer. Et plus important, alors qu'il était relativement facile pour moi de mettre en œuvre de nouveaux modules (après tout, j'ai conçu la chose), il était très difficile de programmer. J'ai fini par apprendre beaucoup de classloaders, mais c'était tout.