انواع modifier در جاوا

modifier ها در جاوا به دو دسته کلی تقسیم بندی میشوند :

آنهایی که سطح دسترسی را تعیین میکنند

آنهایی که تاثیر در عملیات میگذارند

 

public :

private :

protected :

default :

 

حوزه دید (SCOPE)	DEFAULT	PRIVATE	PROTECTED	PUBLIC
همان کلاس	Yes	Yes	Yes	Yes
ساب کلاس های همان پکیج	Yes	No	Yes	Yes
کلاس های معمولی همان پکیج	Yes	No	Yes	Yes
ساب کلاس های پکیج دیگر	No	No	Yes	Yes
کلاس های معمولی پکیج دیگر	No	No	No	Yes

strictfp : روی متد تعریف میشود و باعث میشود عملیات محاسبات اعشاری با دقت کمتری اجرا شوند و اینطوری نتیجه ای یکسان در کل سخت افزار های مختلف خواهیم داشت ولی اگر استفاده نکنیم دقت عملیات اعشاری بالاتر خواهند بود

static : متد ها و فیلد های کلاس میتوانند این modifier را داشته باشند و هنگامی استفاده میشود که برای دسترسی به آن متد با فیلد نیازی به Object جدید نداریم و زمانی از این modifier روی متد استفاده میکنیم که این متد با هیچ فیلد و Object خاصی وابستگی نداشته باشد و برای کار نیازی نیست که data type ای در حافظه Allocate شود ، از داخل متد static به فیلد های non-static دسترسی نداریم و باید بصورت آرگومان دیتا ارسال شود متد ها و فیلد های این نوع دیگر بصورت dynamic لود نمیشوند و سرعت اجرای بالاتری را دارند

final : اگر روی کلاس تعریف شود آن کلاس قابل ارث بری نیست ، اگر روی متد تعریف شود آن متد قابل override شدن نیست و اگر روی متغیر های primitive استفاده شود مقدار متغییر قابل تغییر نیست و اگر روی متغیر های reference تعریف شوند instance جدید نمیتواند به آن متغیر منتسب شود 

synchronized : جهت استفاده در thread ها میتوان یک سری عملیات را بدون تداخل با thread دیگری در یک synchronized block اجرا کرد در حقیقت یک قفل اجرای موقتی که مجوز استفاده در لحظه تنها یک ترد را ایجاد میکند تا از ورود ترد ها دیگر و تداخل در عملیات جلوگیری شود

volatile :جهت استفاده در thread ها ، هر ترد هنگام انجام عملیات یک stack مختص به خود را دارد و وقتی با متغییر ها بخواهد کار کند یک cache از آنها ایجاد میکند و با آنها کار میکند حال یک ترد دیگر ممکن است اصلاعات متغیر را تغییر دهد و این میتواند خروجی عملیات ترد قبلی را نا معتبر کند برای جلوگیری از این حالت ، میتوان آن متغیر را از نوع volatile تعیین کرد و جاوا با این نوع متغیر ها بصورت atomic ( اتمیک بودن عملیات همانطور که در بحث دیتابیس های رابطه ای هم داریم یا کل عملیات یکباره انجام میشود و یا کل عملیات انجام نمیشود ) برخورد میکند یعنی هنگامی که متغیر در حال تغییر است بقیه ترد ها حق خواندن از آن متغییر را نخواهند داشت و وقتی که مقدار جدیدی به متغییر انتساب داده شد بقیه thread ها هم آنرا بصورت بروز شده میبینند در حقیقت جاوا اجازه نمیدهد که آن متغیر در stack/cache ترد ذخیره شود و آنرا در heap نگهداری میکند البته اینکار سرعت اجرا را به مراتب کند میکند اما در مالتی ترد بودن عملیات ، اطلاعات صحت خود را حفظ میکنند

- استفاده از کلمات کلیدی final  و volatile باهم تداخل خواهد داشت چون متغییری که از نوع volatile تعیین میشود به آن معناست که در آینده تغییراتی را میپذیرد

کاربرد volatile : هنگامی که یک shared resource داریم و میخواهیم آنرا بین ترد های مختلف به اشتراک بگذاریم عملی مشابه با بلاک های synchronized ولی تفاوت با آن چیست :

- در جاهایی که فقط تغییرات shared resoruce شامل خواندن و نوشتن روی یک متغییر است نوع متغییرهای atomic بسیار بهینه تر از synchronized عملی میکنند که عموما عملیات نوشتن (تغییر متغیر) توسط یک ترد و عملیات خواندن توسط تعداد زیادی صورت میگیرد

- در متغیرهای atomic قفل بر روی read/write یک متغییر گذاشته میشود ولی در بلاک های synchronized ما میتوانیم یک مجموعه عملیات را در یک بلاک بصورت اتمیک اجرا کنیم از این رو با بلاک synchronized میتوان مسایل بزرگتر و پیچیده تری را حل کرد

نکته : در سیستم های 32 بیتی متغییر های 64 بیتی مثل long و double  در دو آدرس حافظه 32 بیتی نگهداری میشوند و در هنگام تغییر مقادیر یک متغیر 64 بیتی عملیات آن atomic نیستند و هنگامی که 32 بیت اول در حال تغییر است میتواند 32 بیت دوم توسط ترد دیگری از قبل در حال تغییر باشد و باید حواسمان باشد که در برنامه های مالتی ترد در سیستم های 32 بیتی این نوع از متغییر ها را یا از نوع AtomicLong و ... استفاده کنیم و یا از نوع volatile

transient : هنگام عملیات Serializable فیلدهای transient ذخیره نمیشوند

native : برای متد هایی که از طریق JNI با native کد ها در ارتباط هستند