نحوه مديريت حافظه در JTable و ArrayList

[kobari]

سلام
دوستاني كه در مورد نحوه مديريت حافظه در JTabel و ArrayList اطلاع دارند لطفا به اين سئوال پاسخ دهند :
در استفاده از JTabel و ArrayList آيا محدوديي از نظر حجم ديتا وجود دارد يا ميتوان با اطمينان اطلاعات حجيم را در آنها نگهداري كرد ؟ اگر محدوديتي هست سقف آن چقدر است ؟ آيا اين دو كلاس فقط از Memory براي نگهداري ديتا استفاده مي كنند يا اينكه در صورت لزوم از فضاي Hard disk نيز بعنوان حافظه كمكي براي نگه داري ديتا استفاده مي كنند؟ در صورت وجود محدوديت از چه ابزار يا روشي بايد براي نگهداري داده هاي پر حجم در جاوا استفاده كرد؟

[jeus]

برای سئوال اولت اینکه در ابتدا بله در memory ذخیره میکنند و همینطور که میدونی arraylist یک آرایه بدون محدودیت میباشد که میتونه توی خودش کلاسها رو نگهداری کنه سرعتش پایین تر از آرایه هست ولی احتیاج به تعریف تعداد سطرها در ابتدای کار نداره
اطلاعات arraylist را میتونی روی هارد هم ذخیره کنی به وسیله hashtable بهترین ابزار دیتا بیس است که تو میتونی از دیتا بیسهایی که bind میشوند نیز استفاده کنی مانند sqlite
موفق باشی

[kobari]

برای سئوال اولت اینکه در ابتدا بله در memory ذخیره میکنند و همینطور که میدونی arraylist یک آرایه بدون محدودیت میباشد که میتونه توی خودش کلاسها رو نگهداری کنه سرعتش پایین تر از آرایه هست ولی احتیاج به تعریف تعداد سطرها در ابتدای کار نداره
اطلاعات arraylist را میتونی روی هارد هم ذخیره کنی به وسیله hashtable بهترین ابزار دیتا بیس است که تو میتونی از دیتا بیسهایی که bind میشوند نیز استفاده کنی مانند sqlite
موفق باشی
با سلام
ضمن تشكر از پاسختان ،‌لطفا كمي دقيقتر منظور خود را در مورد آرایه بدون محدودیت بيان كنيد. بلاخره يك نرم افزار هميشه تابع محدوديت هاي سخت افزاري است و وقتي به سقف اين محدديت ، در اينجا memory برسد،‌ چه اتفاقي ميافتد ؟ آيا از ادامه ذخيره سازي باز مي ماند يا اينكه تا آنجا كه امكان دارد از فضاي هارد بعنوان secondary memory استفاده ميكند،‌ تا اينكه فضاي هارد نيز به پايان برسد و آنوقت توليد خطا مي كند.
من دنبال اين هستم كه بدانم وقتي كه ابزارهاي جاوا كه بايد چندين گيگا بايت اطلاعات را براي پردازش ،بر روي كامپيوتري كه فقط يك گيگ بايت حافظه دارد، در خود ذخيره كنند، چگونه بايد برخورد بايد كرد . آيا برنامه خود بايد مراقب اين مسائل يعني كنترل فضاي حافظه باشد يا اينكه ابزارهاي جاوا بصورت transparent اين مديريت را انجام ميدهند و هيچ گونه نگراني براي برنامه نويس از بابت داده هاي حجيم باقي نخواهد گذاشت.

[mazdadoost]

دوست عزیز :kobari
در جوب شما باید عرض کنم چه در مورد JTable و ArrayList و چه هر شی دیگری کنترل و مدیریت حافظه مصرفی برای جاوا از طریق روتین ها و آلگوریتم های خود کار
یعنیgarbage collector یا همون زباله روب انجام میشند.و برنامه نویس کنترلی بر روی این فرایند نداره.هر شی ای که در برنامه ساخته میشه دارای یه طول عمر هست. در کل 2 جور طول عمر برای زباله روب هست.اشیاء کم عمر و اشیاء با همر طولانی.
اشیاء کم عمر با الویت کمتر و طولانی عمر با الویت بیشتری از حافظه پاک میشند.چه وقت یه شی از حافظه پاک میشه؟در کل وقتی تمام ارجاعات(به بیانی اشارگر های ضمنی به اون شی ) صفر بشن .
خوب حالا ببینیم چقدر حافظه در دسترس یه برنامه جاوا که در واقع کدی هست که در JVM اجرا میشه هست؟اول حافظه فیزیکی سیستم یا همون RAM :هر چقدر که Heap تعریف بشه از مثلا یک مگابایت تا چندین گیگا بایت.پس هر چقدر در موقع شروع برنامه Heap بیشتری براش تعریف بشه رم بیشتری هم در اختیار اشیاء برنامه خواهد بود.دوم بستگی به پلت فرم داره:در صورتی که سیستم عامل به نحوی از حافظه مجازی مثلا Memory Maping پشتیبانی بکنه JVM سعی میکنه در وهله اول اشیاء با عمر طولانی و در ادامه اشیاء با عمر کم رو به سیستم عامل برای قرار دادن به حافظه مجازی بسپاره.این یعنی در مقام تئوری برنامه شما از حافظه نسبتا نا محدودی استفاده بکنه. اما در عمل مسائلی هست که رسیدن به این نا محدودی رو محدود میکنه.مثلا جدولی که JVM برای آدرس اشیائی که در حافظه مجازی نگاشت شدن نگه می داره در Heap(RAM)ذخیره میشه.در نهایت ای جدول هم پر میشه و برنامه دیگه نمیتونه اشیاء دیگری رو در حافظه نگاشت کنه.این جاست که با OUT Of Memory مواجه میشید!
مسئله بعدی کارایی برنامه هست!برای مثال حالتی رو تصور کنید که برنامه شما باید آرایه ای از استریم ها که هر کدوم حجمی حدود 1 تا دو مگا بایت رو دارند مدیریت کنه.در این حالت gc و الگوریتم هاش می تونن واقعا سرعت برنامه رو برای پاک سازی اشیاء بی مصرف بگیرند!(با وجود اینکه ریسمان gc یک ریسمان با الویت پایین هست!)
در مورد بعدی طول عمر برنامه شماست که میتونه به شما بگه چقدر باید نگران حافظه مصرفی برای برنامه باشید.برنامه ای که قراره نهایتا چند ساعت اجرا بشه حتی اگه اشیاء بی مصرف زیادی داشته باشه در نهایت با خارج شدن از JVM منابع مصرفیش آزاد میشه.اما برنامه ای که قراره روز ها ماهها و سالها در یک سر ور به صورت 24 ساعته در حال کار باشه حتما باید از نظر حافظه بهینه بشه.
در جاوا شما میتونید به gc در کارش از چند روش کمک کنید(فقط کمک هیچ کدوم از این کمک ها نمی تونه تضمین کنه که دقیقا زمان پاک شدن یه شئ توسط gc چه وقته):
1-مقدار شی رو به null ست کنید.
2-در بلاک finaly شی رو null کنید .
3-استفاده از weak refrence ها.
4-در نهایت با اجرای متد System.gc() به شکل صریح gc رو فراخانی کنید.
امید وارم مفید بوده باشه.
موفق باشید.

[kobari]

دوست عزیز :kobari
.در نهایت ای جدول هم پر میشه و برنامه دیگه نمیتونه اشیاء دیگری رو در حافظه نگاشت کنه.این جاست که با OUT Of Memory مواجه میشید!
.

جناب mazdadoost ضمن سلام واقعآ از توضيحات كامل شما متشكرم.
اين جمله شما دقيقا آن مشكلي است است كه من مي خواهم آن را تحت كنترل برنامه در آورم و تحت هيچ شرايطي برخورد با اين استثناء مانع ادامه كار برنامه نشه. براي توضيح بيشتر برنامه ام را تشريح ميكنم : يك فرم گزارش گيري است كه بصورت Query By Exampleدر اختيار كاربر قرار ميگيره و كاربر با توجه به شرايط جستجو كه در فرم وارد مي كنه N ركورد را از ديتا بيس بازيابي ميكنه . نتيجه اين باز يابي در يك JTable ذخير ميشند و كاربر پس از حذف ستونهاي نا خواسته در JTable، محتواي آنرا در نهايت پرينت خواهد گرفت. حال اگر در هنگام اجراي برنامه با OUT Of Memory روبرو شد در حقيقت گزارش غير كاملي بدستش خواهد رسيد.
اين برنامه تحت ويندوز روي يك پي سي معمولي كار خواهد كرد و نكته مهم اين است كه با توجه به كاربردهايي كه از اين برنامه استفاده خواهند كرد حجم ديتاي آنها كاملا متفاوت است و من بدنبال آن هستم كه حد الامكان پيش نياز سخت افزاري براي نرم افزار تعيين نكنم و بتوانم با راه حل هاي نرم افزاري اين محدوديت ها را تحت كنترل در آورم و نتايج جستجوي كاربر را بطور كامل در اختيارش قرار دهم حتي اگر از يك پي سي با رم يك گيگ استفاده كند و حجم ديتاي آن برايم غير قابل پيش بيني باشد. بنظر شما از چه راه كارهايي بايد براي اين منظور استفاده كنم؟

[mazdadoost]

دوست عزیز : kobari
ضمن تشکر از لطف شما :
1-بد نیست یاداوری کنم یک مشکل دیگه gc در کار با حافظه اینه که گاهی سرعت ایجاد اشیائ جدید به قدری بالاست که قبل از اینکه فرصت برای پاکسازی پیش بیاد Heap کاملا پر میشه!
2-یه راه میتونه این باشه :
*)فرض کنید جدول شما در یه کادر 640*480 نمایش داده میشه و در این حالت حدود 50 سطر نمایش داده میشه.(یک صفحه)
*)میتونید محاسبه کنید که تعداد کل سطر ها چقدره.و چند صفحه میشه.مثلا 3000 صفحه!
*)با پرو فایلر چک کنبد که لود کردن چند صفحه در حد اقل heap مورد نظر شما مثلا 200 مگابایت حافظه رو با مشکل مواجه نمی کنه.فرض میکنیم با 500 صفحه هیچ مشکلی پیش نمیاد.
*)حالا باید یه ریسمان راه اندازی کنید .و یک بافر بسازید.اندازه بافر به اندازه 500 صفحه باید باشه(میتونید با عملگر sizeof استفاده کنید )وظیفه ریسمان به این شکله که وقتی کاربر در جدول شما اسکرول میکنه داده های بافر رو از دیتا بیس در حدود بالایی و پایینی نمایه 800*600 پیکسلی شما از دیتابیس بخونه و در بافر 500 صفحه ای بذاره!
اینطور میتونید تضمین کنید که برنامه با حد اقلی که مورد نظر شماست کار میکنه.
*)در نهایت هم میتونید باتست بیشتر کاری کنید که برنامه بتونه با توجه به heap سایز بزرگتر تعداد صفحات بیشتری رو در بافر بارگذاری کنه.

این ایده کاره.بنده این کارو در یه برنامه imaging تجربه کردم.در اون جا مشکلی که داشتم بار کردن فایل های سکئنس دایکام با حجم حدود 10 تا 600 مگابایت در ram با ظرفیت 2 گیگا بایت بود.
راه حل های دیگری هم هست.مثل OSCach:http://www.opensymphony.com/oscache/.
موفق باشید.

[kobari]

دوست عزیز : kobari
ضمن تشکر از لطف شما :
1-بد نیست یاداوری کنم یک مشکل دیگه gc در کار با حافظه اینه که گاهی سرعت ایجاد اشیائ جدید به قدری بالاست که قبل از اینکه فرصت برای پاکسازی پیش بیاد Heap کاملا پر میشه!
2-یه راه میتونه این باشه :
*)فرض کنید جدول شما در یه کادر 640*480 نمایش داده میشه و در این حالت حدود 50 سطر نمایش داده میشه.(یک صفحه)
*)میتونید محاسبه کنید که تعداد کل سطر ها چقدره.و چند صفحه میشه.مثلا 3000 صفحه!
*)با پرو فایلر چک کنبد که لود کردن چند صفحه در حد اقل heap مورد نظر شما مثلا 200 مگابایت حافظه رو با مشکل مواجه نمی کنه.فرض میکنیم با 500 صفحه هیچ مشکلی پیش نمیاد.
*)حالا باید یه ریسمان راه اندازی کنید .و یک بافر بسازید.اندازه بافر به اندازه 500 صفحه باید باشه(میتونید با عملگر sizeof استفاده کنید )وظیفه ریسمان به این شکله که وقتی کاربر در جدول شما اسکرول میکنه داده های بافر رو از دیتا بیس در حدود بالایی و پایینی نمایه 800*600 پیکسلی شما از دیتابیس بخونه و در بافر 500 صفحه ای بذاره!
اینطور میتونید تضمین کنید که برنامه با حد اقلی که مورد نظر شماست کار میکنه.
*)در نهایت هم میتونید باتست بیشتر کاری کنید که برنامه بتونه با توجه به heap سایز بزرگتر تعداد صفحات بیشتری رو در بافر بارگذاری کنه.

این ایده کاره.بنده این کارو در یه برنامه imaging تجربه کردم.در اون جا مشکلی که داشتم بار کردن فایل های سکئنس دایکام با حجم حدود 10 تا 600 مگابایت در ram با ظرفیت 2 گیگا بایت بود.
راه حل های دیگری هم هست.مثل OSCach:http://www.opensymphony.com/oscache/.
موفق باشید.
جناب mazdadoost سلام و مرسي از كمكتان. چيزي شبيه راه حلتان در ذهنم بود كه توضيح شما كمك فراواني كرد تا موضوع بصورت دققيقتر در ذهنم شكل گيرد . راه حل ارائه شده در لينك بالا هم خيلي جالب و وسوسه انگيز است كه بعد از مطالعه بيشتر در مورد استفاده از آن تصميم خواهم گرفت. از وقتي كه بمن اختصاص داديد تشكر ميكنم.

[kobari]

3-استفاده از weak refrence ها.
.
جناب mazdadoost با سلام
من WeakReference را در یک برنامه که در یک لوپ بی پایان یک مگابایت حافظه را در هر گذر allocate می کرد چک کردم و برنامه بدون هیچ مشکلی به کار خود ادامه می دهد. بعد از چندین بار تست و مشاهده خروجی تشخیص داده شد که بعد از هر 3 بار گذر از لوپ gc شروع به پاک سازی آبژکت های تخصیص داده شده می کند و در نتیجه هر 3 ابژکت ایجاد شده از حافظه پاک میشوند و این در صورتی است که هنوز کلی از منابع حافظه در سیستم باقی است. آیا با این وجود میتوان اطمینان پیدا کرد که آبژکتهای ایجاد شده قبل از پاک شدن ، حتمآ مورد پرادازش قرار گرفته باشند ؟

[mazdadoost]

با عرض سلام :
ضمن پوزش بابت دیر شدن جواب .
در مورد gc مسئله مهم اینه که وقتی تمام مراجع به یک شی null شد به صورت یک شکل قابل حذف مارک میشه و به محضه اینکه شرایط مطلوب برای پاک کردنه اون شی فراهم شد gc پاکش میکنه!
موفق باشید.