Question

Nous déployons une application sur un périphérique semi-intégré soumis à des contraintes de mémoire. Nous cherchons à économiser ce que nous pouvons, nous analysons les décharges de tas de l'application et attaquons les plus gros consommateurs.

Nous utilisons Spring 2.5 avec Spring DM 1.1 et nous remarquons que certains de nos bundles dans des contextes Spring plus complexes utilisent beaucoup de mémoire, car Spring semble conserver le graphe d'objet entier contenant toutes les définitions de BeanDéfinies analysées. à partir du XML. Je suppose que la plupart de cela est inutile une fois que l'application a été initialisée et que tout est injecté.

Existe-t-il des options de configuration pour Spring qui permettent de contrôler ce comportement? Exécuter en mode mémoire faible? Jeter toutes les choses inutiles? Commerce temps de calcul pour la taille?

Était-ce utile?

La solution

J'ai demandé à des membres de l'équipe d'examiner cette question plus en profondeur et d'obtenir des résultats intéressants. Spring, dans sa configuration par défaut, n’est pas intéressé par une utilisation particulièrement conservatrice de la mémoire. Deux aspects fondamentaux peuvent être modifiés pour obtenir des gains significatifs:

  • La première est une propriété non exposée dans le ressort OsgiBundleXmlApplicationContext que vous pouvez remplacer si vous étendez à partir de cette classe et que vous substituez la méthode customizeBeanFactory.

Nous l'avons fait comme ceci:

@Override
protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
    super.customizeBeanFactory(beanFactory);
    String cacheBeanMetadataSysProp = System.getProperty(CACHE_BEAN_METADATA, "true");
    if (cacheBeanMetadataSysProp != null
        && cacheBeanMetadataSysProp.equalsIgnoreCase("false")) {
        beanFactory.setCacheBeanMetadata(false);
    } else if (cacheBeanMetadataSysProp != null
        && cacheBeanMetadataSysProp.equalsIgnoreCase("true")) {
        beanFactory.setCacheBeanMetadata(true);
    }
}

Définition de la " setCacheBeanMetadata & "; propriété sur false entraîne la suppression du BeanDefinitions (essentiellement le miroir de programmation de votre configuration basée sur XML) après l’initialisation.

  • Le deuxième changement - pour lequel nous avons actuellement un prototype - est un correctif pour le code source Spring qui permet d’initialiser les collections paresseux. Il s'avère que de nombreux objets Spring internes qui représentent des Beans et toutes leurs propriétés ont beaucoup de membres qui sont initialisés à HashMaps et à d'autres collections, mais sont très rarement remplis de données. Changer le framework Spring pour les initialiser paresseusement économisera une autre quantité de mémoire, mais il s’agit d’un changement beaucoup plus invasif.

Autres conseils

Vous pouvez enregistrer une mémoire avec un BeanFactory - voir 3.8.1. BeanFactory ou ApplicationContext :

  

Etant donné que le contexte d'application inclut toutes les fonctionnalités de BeanFactory, il est généralement recommandé de l'utiliser de préférence à BeanFactory, à l'exception de quelques situations limitées, telles que celles d'une applet, dans lesquelles la consommation de mémoire peut être critique et quelques kilo-octets supplémentaires. pourrait faire une différence.

Je ne connais aucun moyen de faire courir Spring dans & "light &"; mode. Vous pouvez essayer d'implémenter un BeanFactoryPostProcessor et l'utiliser pour supprimer certains beans du contexte. Je ne sais pas si cela va cependant entraîner des erreurs internes au printemps.

Si vous utilisez uniquement Spring au démarrage, c'est-à-dire , tous les beans sont câblés et vous n'avez pas besoin du contexte de l'application ni de la logique d'arrêt, vous pouvez démarrer votre application. puis effacez toutes les références au contexte de l'application.

Si votre configuration Spring utilise AOP et le temps de chargement, vous pouvez utiliser aop.xml pour récupérer de la mémoire dans AspectJ à l'aide de la fonctionnalité de rétrogradation de type AspectJ introduite dans 1.6.5.

<weaver options="-Xset:typeDemotion=true"/>

Analysez votre tas, si vous trouvez plusieurs objets RefType, l'astuce ci-dessus vous aidera.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top