سؤال

نحن نقوم بنشر تطبيق على جهاز شبه مدمج به قيود على الذاكرة.سعيًا إلى حفظ كل ما في وسعنا، نقوم بتحليل مقالب الكومة من التطبيق ومهاجمة أكبر المستهلكين.

نحن نستخدم Spring 2.5 مع Spring DM 1.1 ونلاحظ أن بعض حزمنا ذات سياقات Spring الأكثر تعقيدًا تستخدم قدرًا كبيرًا من الذاكرة حيث يبدو أن Spring يحتفظ بالرسم البياني للكائن بالكامل والذي يحتوي على جميع تعريفات BeanDefinitions التي تم تحليلها من XML .أفترض أن معظم هذا غير ضروري بمجرد تهيئة التطبيق وإدخال كل شيء.

هل هناك خيارات تكوين لـ Spring تسمح للشخص بالتحكم في هذا السلوك؟تشغيل في بعض وضع الذاكرة المنخفضة؟رمي بعيدا كل الأشياء غير الضرورية؟وقت حساب التجارة للحجم؟

هل كانت مفيدة؟

المحلول

لقد قمت بإلقاء نظرة أعمق على هذا الأمر من قبل أعضاء الفريق وحصلت على بعض النتائج المثيرة للاهتمام.الربيع في تكوينه الافتراضي لا يهتم كثيرًا بالتحفظ بشكل خاص في استخدام الذاكرة.هناك جانبان أساسيان يمكن تعديلهما لتحقيق مكاسب كبيرة:

  • الأول هو خاصية غير مكشوفة داخل الربيع OsgiBundleXmlApplicationContext أنه يمكنك التجاوز إذا قمت بالتوسيع من تلك الفئة وتجاوز customizeBeanFactory طريقة.

لقد فعلنا ذلك مثل هذا:

@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);
    }
}

تعيين خاصية "setCacheBeanMetadata" على false يسبب BeanDefinitions (في الأساس المرآة البرمجية للتكوين المستند إلى XML الخاص بك) ليتم التخلص منها بعد التهيئة.

  • التغيير الثاني - الذي لدينا حاليًا نموذج أولي له - هو تصحيح لكود مصدر Spring لإجراء التهيئة البطيئة للمجموعات.اتضح أن العديد من كائنات Spring الداخلية التي تمثل Beans وجميع خصائصها تحتوي على الكثير من الأعضاء الذين تمت تهيئتهم لـ HashMaps والمجموعات الأخرى افتراضيًا ولكن نادرًا ما يتم ملؤهم بالبيانات.سيؤدي تغيير إطار عمل Spring لتهيئة هذه العناصر بتكاسل إلى توفير قدر كبير آخر من الذاكرة ولكنه تغيير أكثر تدخلاً.

نصائح أخرى

ويمكنك حفظ <م> بعض الذاكرة مع BeanFactory - يرى <وأ href = "http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#context -introduction-CTX-مقابل-beanfactory "يختلط =" نوفولو noreferrer "> 3.8.1. BeanFactory أو ApplicationContext :

<اقتباس فقرة>   

وكما ApplicationContext يشمل جميع وظائف من BeanFactory، فمن المستحسن عموما في ذلك استخدامها في الأفضلية لBeanFactory، باستثناء عدد قليل من حالات محدودة مثل في الصغير، حيث استهلاك الذاكرة قد تكون حاسمة وعدد قليل كيلوبايت إضافية قد تحدث فرقا.

وأنا لست على علم بأي طريقة لجعل المدى الربيع في وضع "خفيفة". قد تتمكن من محاولة تنفيذ BeanFactoryPostProcessor واستخدامه لإزالة بعض الفاصوليا من السياق. ليس لدي أي فكرة سواء كان ذلك سوف يؤدي إلى أخطاء الربيع الداخلية ولكن.

إذا كنت تستخدم فقط الربيع عند بدء التشغيل، <م> أي يتم السلكية جميع حبوب ومن ثم لا تحتاج سياق تطبيق أو منطق الاغلاق، ويمكنك البدء في التطبيق ثم قم بإلغاء تحديد كل ما يشير إلى سياق التطبيق.

وإذا كان يستخدم التكوين الربيع الخاص اوب ووقت التحميل النسيج، يمكنك استخدام aop.xml لاستعادة بعض الذاكرة من AspectJ باستخدام AspectJ ميزة نوع التخفيض الذي تم تقديمه في 1.6.5.

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

وتحليل كومة الخاص بك، إذا وجدت العديد من الكائنات RefType، خدعة فوق ستساعد.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top