JAVA(1) JDK Commands JAVA(1)

java - راه‌انداز و مفسر اجرای برنامه‌های جاوا (نسخه ۲۵)

برای راه‌اندازی یک فایل کلاس:

java [گزینه‌ها] mainclass [آرگومان‌ها ...]

برای راه‌اندازی کلاس اصلی در یک فایل JAR:

java [گزینه‌ها] -jar jarfile [آرگومان‌ها ...]

برای راه‌اندازی کلاس اصلی در یک ماژول:

java [گزینه‌ها] -m module[/mainclass] [آرگومان‌ها ...]

یا

java [گزینه‌ها] --module module[/mainclass] [آرگومان‌ها ...]

برای راه‌اندازی برنامه سورس‌کد:

java [گزینه‌ها] source-file [آرگومان‌ها ...]

اختیاری: گزینه‌های خط فرمان را که با فاصله از هم جدا شده‌اند مشخص می‌کند. برای مشاهده شرح گزینه‌های موجود به بخش مرور کلی گزینه‌های جاوا (OVERVIEW OF JAVA OPTIONS) مراجعه کنید.
نام کلاسی که باید اجرا شود را مشخص می‌کند. ورودی‌های خط فرمان بعد از classname به عنوان آرگومان‌های متد اصلی (main) در نظر گرفته می‌شوند.
برنامه‌ای را که درون یک فایل JAR بسته‌بندی شده است اجرا می‌کند. آرگومان jarfile نام یک فایل JAR همراه با مانیفست است که حاوی خطی به فرم Main-Class:classname است؛ کلاسی که متد public static void main(String[] args) را به عنوان نقطه شروع برنامه شما تعریف می‌کند. هنگام استفاده از -jar، فایل JAR مشخص‌شده منبع تمامی کلاس‌های کاربر خواهد بود و سایر تنظیمات مسیر کلاس (class path) نادیده گرفته می‌شوند. اگر از فایل‌های JAR استفاده می‌کنید، دستور jar را ببینید.
کلاس اصلی را در ماژول مشخص‌شده با mainclass (در صورت تعیین) یا مقدار پیش‌فرض تعریف‌شده در module اجرا می‌کند. به عبارت دیگر، mainclass را می‌توان در صورتی که توسط ماژول مشخص نشده باشد استفاده کرد، یا برای بازنویسی مقداری که ماژول مشخص کرده به کار برد.
بخش گزینه‌های استاندارد جاوا (STANDARD OPTIONS FOR JAVA) را ببینید.
فقط برای راه‌اندازی برنامه در حالت سورس‌فایل استفاده می‌شود. فایل سورسی را که حاوی کلاس اصلی در هنگام استفاده از حالت سورس‌فایل است مشخص می‌کند. بخش استفاده از حالت فایل سورس برای اجرای برنامه‌های سورس‌کد (USING SOURCE-FILE MODE TO LAUNCH SOURCE-CODE PROGRAMS) را ببینید.
اختیاری: آرگومان‌های پس از mainclass، source-file، -jar jarfile و -m یا --module module/mainclass به عنوان آرگومان به کلاس اصلی فرستاده می‌شوند.

دستور java یک برنامه کاربردی جاوا را اجرا می‌کند. این کار را با راه‌اندازی ماشین مجازی جاوا (JVM)، بارگذاری کلاس مشخص‌شده و فراخوانی متد main() آن کلاس انجام می‌دهد. این متد باید به صورت public و static اعلان شده باشد، نباید هیچ مقداری برگرداند و باید یک آرایه String را به عنوان پارامتر بپذیرد. اعلان متد دارای فرم زیر است:

public static void main(String[] args)

در حالت سورس‌فایل، دستور java می‌تواند کلاسی را که درون یک فایل سورس اعلان شده است راه‌اندازی کند. برای مشاهده شرح استفاده از حالت سورس‌فایل، به بخش استفاده از حالت فایل سورس برای اجرای برنامه‌های سورس‌کد (USING SOURCE-FILE MODE TO LAUNCH SOURCE-CODE PROGRAMS) مراجعه کنید.

نکته: می‌توانید از متغیر محیطی JDK_JAVA_OPTIONS برای افزودن محتوای آن به ابتدای خط فرمان واقعی راه‌انداز java استفاده کنید. بخش استفاده از متغیر محیطی JDK_JAVA_OPTIONS (USING THE JDK_JAVA_OPTIONS LAUNCHER ENVIRONMENT VARIABLE) را ببینید.

به‌طور پیش‌فرض، اولین آرگومانی که گزینه دستور java نباشد، نام کامل (fully qualified) کلاسی است که باید فراخوانی شود. اگر -jar مشخص شده باشد، آرگومان آن نام فایل JAR حاوی کلاس‌ها و فایل‌های منبع برنامه است. کلاس آغازین باید توسط هدر مانیفست Main-Class در فایل مانیفست آن مشخص شده باشد.

آرگومان‌های پس از نام فایل کلاس یا نام فایل JAR به متد main() ارسال می‌شوند.

ویندوز: دستور javaw مشابه دستور java است، با این تفاوت که با javaw هیچ پنجره کنسولی همراه نیست. زمانی که نمی‌خواهید پنجره خط فرمان ظاهر شود از javaw استفاده کنید. با این حال، راه‌انداز javaw در صورت بروز خطا در راه‌اندازی، یک کادر محاوره‌ای حاوی اطلاعات خطا نمایش می‌دهد.

برای راه‌اندازی کلاسی که در یک فایل سورس اعلان شده است، راه‌انداز java را در حالت سورس‌فایل اجرا کنید. ورود به حالت سورس‌فایل توسط دو مورد در خط فرمان java تعیین می‌شود:

  • اولین مورد در خط فرمان که گزینه یا بخشی از یک گزینه نباشد. به عبارت دیگر، موردی در خط فرمان که در غیر این صورت نام کلاس اصلی خواهد بود.
  • گزینه -urce version در صورت وجود.

اگر شناسه کلاس به یک فایل موجود با پسوند .java اشاره کند، یا اگر گزینه -urce مشخص شده باشد، حالت سورس‌فایل انتخاب می‌شود. سپس فایل سورس کامپایل و اجرا می‌گردد. گزینه -urce می‌تواند برای مشخص کردن نسخه سورس (version یا N) سورس‌کد استفاده شود. این گزینه مشخص می‌کند چه رابط برنامه‌نویسی (API) قابل استفاده است. وقتی -urce N را تنظیم می‌کنید، تنها می‌توانید از رابط عمومی برنامه‌نویسی که در JDK N تعریف شده استفاده کنید.

نکته: مقادیر معتبر N در هر نسخه تغییر می‌کنند؛ مقادیر جدید اضافه شده و مقادیر قدیمی حذف می‌شوند. اگر از مقداری برای N استفاده کنید که دیگر پشتیبانی نمی‌شود، پیام خطا دریافت خواهید کرد. مقادیر پشتیبانی‌شده برای N عبارتند از نسخه فعلی Java SE (25) و تعداد محدودی از نسخه‌های قبلی، که جزئیات آن در راهنمای خط فرمان javac زیر گزینه‌های -urce و -elease آمده است.

اگر فایل پسوند .java نداشته باشد، باید از گزینه -urce استفاده شود تا به دستور java بگوید از حالت سورس‌فایل استفاده کند. گزینه -urce برای مواردی استفاده می‌شود که فایل سورس یک «اسکریپت» اجرایی است و نام فایل سورس از قراردادهای نام‌گذاری عادی فایل‌های سورس جاوا پیروی نمی‌کند.

در حالت سورس‌فایل، اثر کار به گونه‌ای است که گویی فایل سورس در حافظه کامپایل شده و اولین کلاس یافت‌شده در فایل سورس اجرا می‌شود. هر آرگومانی که بعد از نام فایل سورس در خط فرمان اولیه قرار گیرد، در زمان اجرا به کلاس کامپایل‌شده ارسال می‌شود.

برای مثال، اگر فایلی با نام HelloWorld.java حاوی کلاسی با نام HelloWorld باشد، دستور حالت سورس‌فایل برای راه‌اندازی این کلاس به صورت زیر خواهد بود:

java HelloWorld.java

این استفاده از حالت سورس‌فایل به‌طور غیررسمی معادل اجرای دو دستور زیر است:

javac -d <memory> -urce-path <source-root> HelloWorld.java
java -lass-path <memory> HelloWorld

که در آن <source-root> محاسبه می‌شود.

در حالت سورس‌فایل، گزینه‌های اضافی خط فرمان به صورت زیر پردازش می‌شوند:

•
راه‌انداز گزینه‌های مشخص‌شده پیش از فایل سورس را بررسی می‌کند تا گزینه‌های مرتبط با کامپایل فایل سورس را بیابد.

این موارد شامل: -lass-path، -dule-path، -dd-exports، -dd-modules، -t-modules، -atch-module، -pgrade-module-path و هرگونه شکل تغییریافته از این گزینه‌ها است. همچنین شامل گزینه جدید -\nable-preview می‌شود که در JEP 12 شرح داده شده است.

  • هیچ تمهیدی برای ارسال گزینه‌های اضافی مانند -processor یا -Werror به کامپایلر در نظر گرفته نشده است.
  • فایل‌های آرگومان خط فرمان (@-files) را می‌توان به شیوه استاندارد استفاده کرد. لیست‌های طولانی از آرگومان‌ها برای ماشین مجازی یا برنامه در حال فراخوانی را می‌توان در فایل‌هایی قرار داد و با پیشوند @ در خط فرمان مشخص کرد.

در حالت سورس‌فایل، کامپایل به صورت زیر پیش می‌رود:

  • هر گزینه خط فرمان که به محیط کامپایل مربوط باشد اعمال می‌شود. این گزینه‌ها عبارتند از: -lass-path/-classpath/-cp، -dule-path/-p، -dd-exports، -dd-modules، -t-modules، -atch-module،
    -pgrade-module-path، -\nable-preview.
  • ریشه درخت سورس (<source-root>) بر اساس پکیج کلاسی که راه‌اندازی می‌شود محاسبه می‌گردد. برای مثال، اگر HelloWorld.java کلاس‌های خود را درون پکیج hello اعلان کرده باشد، انتظار می‌رود فایل HelloWorld.java در پوشه somedir/hello/ قرار داشته باشد. در این حالت، somedir به عنوان ریشه درخت سورس محاسبه می‌شود.
  • ریشه درخت سورس به عنوان مسیر سورس (source-path) برای کامپایل عمل می‌کند، تا سایر فایل‌های سورس موجود در آن درخت که توسط HelloWorld نیاز هستند نیز کامپایل شوند.
  • پردازش حاشیه‌نویسی‌ها (Annotation processing) غیرفعال است، گویی -proc:none فعال است.
  • اگر نسخه‌ای از طریق گزینه -urce مشخص شده باشد، مقدار آن به عنوان آرگومان یک گزینه ضمنی -elease برای کامپایل استفاده می‌شود. این کار هم نسخه سورس مورد قبول کامپایلر و هم رابط‌های برنامه‌نویسی سیستمی قابل استفاده توسط کد فایل سورس را تنظیم می‌کند.
  • اگر -\nable-preview مشخص شده باشد، می‌توان از آرگومان‌های -urce N صرف‌نظر کرد. اگر نسخه زمان اجرای جاوا N باشد، گزینه -elease N هنگام کامپایل فایل‌های سورس به صورت ضمنی اعمال می‌شود.
  • اگر یک فایل module-info.java در پوشه <source-root> وجود داشته باشد، اعلان ماژول آن برای تعریف یک ماژول نام‌دار استفاده می‌شود که شامل تمام کلاس‌های کامپایل‌شده از فایل‌های .java در درخت سورس خواهد بود. اگر module-info.java وجود نداشته باشد، تمام کلاس‌های کامپایل‌شده از فایل‌های سورس در بستر ماژول بدون نام (unnamed module) کامپایل می‌شوند.
  • فایل سورسی که راه‌اندازی می‌شود باید شامل یک یا چند کلاس سطح بالا (top-level) باشد، که اولین کلاس به عنوان کلاس اجرایی در نظر گرفته می‌شود.
  • برای فایل سورسی که راه‌اندازی می‌شود، کامپایلر محدودیت اختیاری تعریف‌شده در انتهای بخش 7.6 استاندارد JLS مبنی بر اینکه یک نوع در یک پکیج نام‌دار باید در فایلی با نام آن نوع به‌علاوه پسوند .java قرار داشته باشد را اعمال نمی‌کند.
  • اگر یک فایل سورس حاوی خطا باشد، پیام‌های خطای مناسب در خروجی خطای استاندارد نوشته شده و راه‌انداز با یک کد خروج غیرصفر خارج می‌شود.

در حالت سورس‌فایل، اجرا به صورت زیر پیش می‌رود:

  • کلاسی که باید اجرا شود اولین کلاس سطح بالای یافت‌شده در فایل سورس است. این کلاس باید حاوی اعلان متد ورودی main باشد.
  • کلاس‌های کامپایل‌شده توسط یک کلاس‌لودر اختصاصی بارگذاری می‌شوند که کار را به کلاس‌لودر برنامه محول می‌کند. این بدان معناست که کلاس‌های موجود در مسیر کلاس برنامه نمی‌توانند به هیچ‌یک از کلاس‌های اعلان‌شده در فایل‌های سورس ارجاع دهند.
  • اگر یک فایل module-info.java در پوشه <source-root> وجود داشته باشد، تمام کلاس‌های کامپایل‌شده از فایل‌های .java در درخت سورس درون آن ماژول خواهند بود که به عنوان ماژول ریشه برای اجرای برنامه عمل خواهد کرد. اگر module-info.java وجود نداشته باشد، کلاس‌های کامپایل‌شده در بستر یک ماژول بدون نام اجرا می‌شوند، گویی -dd-modules=ALL-DEFAULT فعال است. این مورد علاوه بر هر گزینه -dd-module دیگری است که ممکن است در خط فرمان مشخص شده باشد.
  • هر آرگومانی که بعد از نام فایل در خط فرمان قرار گیرد به روش معمول به متد اصلی ارسال می‌شود.
  • اگر کلاسی در مسیر کلاس برنامه وجود داشته باشد که نام آن با نام کلاسی که باید اجرا شود یکسان باشد، یک وضعیت خطا خواهد بود.

برای جزئیات کامل، JEP 458: Launch Multi-File Source-Code Programs به نشانی https://openjdk.org/jeps/458 را ببینید.

متغیر محیطی JDK_JAVA_OPTIONS محتوای خود را به ابتدای گزینه‌های دریافت‌شده از خط فرمان اضافه می‌کند. محتوای متغیر محیطی JDK_JAVA_OPTIONS فهرستی از آرگومان‌هاست که با نویسه‌های فاصله خالی (مطابق با تابع isspace()) از هم جدا شده‌اند. این موارد به ابتدای آرگومان‌های خط فرمان ارسالی به راه‌انداز java افزوده می‌شوند. نیازمندی کدگذاری برای این متغیر محیطی همانند خط فرمان java در سیستم است. با محتوای متغیر محیطی JDK_JAVA_OPTIONS دقیقاً همانند مقادیر مشخص‌شده در خط فرمان رفتار می‌شود.

می‌توان از نقل‌قول تکی (') یا دوتایی (") برای دربرگرفتن آرگومان‌های حاوی نویسه‌های فاصله خالی استفاده کرد. تمامی محتوای بین نقل‌قول باز و اولین نقل‌قول بسته متناظر با حذف جفت نقل‌قول حفظ می‌شود. در صورتی که نقل‌قول متناظر پیدا نشود، راه‌انداز با یک پیام خطا متوقف خواهد شد. فایل‌های حاوی آرگومان (@-files) به همان صورتی که در خط فرمان مشخص می‌شوند پشتیبانی می‌گردند. هر نویسه عام (wildcard) لفظی * در محتوای متغیر محیطی JDK_JAVA_OPTIONS بسط داده نمی‌شود و عیناً به VM در حال راه‌اندازی فرستاده می‌شود. برای جلوگیری از سوءاستفاده احتمالی از رفتار JDK_JAVA_OPTIONS، گزینه‌هایی که کلاس اصلی را مشخص می‌کنند (مانند -jar) یا باعث خروج راه‌انداز java بدون اجرای کلاس اصلی می‌شوند (مانند -h) در این متغیر محیطی غیرمجاز هستند. اگر هر یک از این گزینه‌ها در متغیر محیطی ظاهر شوند، راه‌انداز با یک پیام خطا متوقف خواهد شد. هنگامی که JDK_JAVA_OPTIONS تنظیم شده باشد، راه‌انداز پیامی را به عنوان یادآوری در خروجی خطای استاندارد چاپ می‌کند.

مثال:

$ export JDK_JAVA_OPTIONS='-g @file1 -Dprop=value @file2 -Dws.prop="white spaces"'
$ java -Xint @file3

معادل است با خط فرمان:

java -g @file1 -Dprop=value @file2 -Dws.prop="white spaces" -Xint @file3

دستور java از طیف گسترده‌ای از گزینه‌ها در دسته‌بندی‌های زیر پشتیبانی می‌کند:

  • گزینه‌های استاندارد جاوا (Standard Options for Java): گزینه‌هایی که پشتیبانی از آن‌ها توسط تمامی پیاده‌سازی‌های ماشین مجازی جاوا (JVM) تضمین شده است. این گزینه‌ها برای اقدامات رایج مانند بررسی نسخه JRE، تنظیم مسیر کلاس، فعال‌سازی خروجی با جزئیات (verbose) و غیره استفاده می‌شوند.
  • گزینه‌های اضافی جاوا (Extra Options for Java): گزینه‌های عمومی که مختص ماشین مجازی Java HotSpot هستند. پشتیبانی از آن‌ها در تمام پیاده‌سازی‌های JVM تضمین نشده است و ممکن است تغییر کنند. این گزینه‌ها با -X شروع می‌شوند.

گزینه‌های پیشرفته برای استفاده‌های روزمره و عمومی توصیه نمی‌شوند. این موارد گزینه‌های توسعه‌دهندگان برای تنظیم بخش‌های خاصی از عملکرد ماشین مجازی Java HotSpot هستند که اغلب نیازمندی‌های سیستمی ویژه‌ای دارند و ممکن است نیازمند دسترسی ممتاز به پارامترهای پیکربندی سیستم باشند. چندین مثال از تنظیم کارایی در بخش مثال‌های تنظیم کارایی (Performance Tuning Examples) ارائه شده است. پشتیبانی از این گزینه‌ها در همه پیاده‌سازی‌های JVM تضمین نمی‌شود و ممکن است تغییر کنند. گزینه‌های پیشرفته با -XX شروع می‌شوند.

  • گزینه‌های پیشرفته زمان اجرا برای جاوا (Advanced Runtime Options for Java): رفتار زمان اجرای Java HotSpot VM را کنترل می‌کنند.
  • گزینه‌های پیشرفته کامپایلر JIT برای جاوا (Advanced JIT Compiler Options for java): کامپایل پویای زمان اجرا (JIT) انجام‌شده توسط Java HotSpot VM را کنترل می‌کنند.
  • گزینه‌های پیشرفته سرویس‌پذیری برای جاوا (Advanced Serviceability Options for Java): امکان جمع‌آوری اطلاعات سیستم و انجام خطایابی جامع را فراهم می‌کنند.
  • گزینه‌های پیشرفته جمع‌آوری زباله برای جاوا (Advanced Garbage Collection Options for Java): نحوه انجام جمع‌آوری زباله (GC) را توسط Java HotSpot کنترل می‌کنند.

گزینه‌های بولی (Boolean) برای فعال‌سازی قابلیتی که به‌طور پیش‌فرض غیرفعال است یا غیرفعال‌سازی قابلیتی که به‌طور پیش‌فرض فعال است استفاده می‌شوند. چنین گزینه‌هایی به پارامتر نیاز ندارند. گزینه‌های بولی -XX با استفاده از علامت مثبت (-XX:+OptionName) فعال شده و با استفاده از علامت منفی (-XX:-OptionName) غیرفعال می‌شوند.

برای گزینه‌هایی که به آرگومان نیاز دارند، آرگومان ممکن است با فاصله، دو نقطه (:) یا علامت مساوی (=) از نام گزینه جدا شود، یا ممکن است آرگومان بلافاصله پس از گزینه بیاید (سینتکس دقیق برای هر گزینه متفاوت است). اگر باید اندازه را به بایت مشخص کنید، می‌توانید از هیچ پسوندی استفاده نکنید، یا از پسوند k یا K برای کیلوبایت (KB)، m یا M برای مگابایت (MB) یا g یا G برای گیگابایت (GB) استفاده کنید. برای مثال، جهت تنظیم اندازه روی ۸ گیگابایت، می‌توانید یکی از مقادیر 8g، 8192m، 8388608k یا 8589934592 را به عنوان آرگومان مشخص کنید. اگر باید درصد را مشخص کنید، از عددی بین ۰ تا ۱ استفاده کنید. برای مثال، مقدار 0.25 را برای ۲۵٪ مشخص نمایید.

بخش‌های زیر گزینه‌های منسوخ، از رده خارج و حذف‌شده را شرح می‌دهند:

  • گزینه‌های منسوخ‌شده جاوا (Deprecated Java Options): پذیرفته می‌شوند و اثر می‌کنند -- - در صورت استفاده از آن‌ها هشدار صادر می‌شود.
  • گزینه‌های متروکه جاوا (Obsolete Java Options): پذیرفته می‌شوند اما نادیده گرفته می‌شوند -- - در صورت استفاده از آن‌ها هشدار صادر می‌شود.
  • گزینه‌های حذف‌شده جاوا (Removed Java Options): حذف شده‌اند -- - استفاده از آن‌ها منجر به خطا می‌شود.

این گزینه‌ها پرکاربردترین گزینه‌هایی هستند که توسط تمامی پیاده‌سازی‌های JVM پشتیبانی می‌شوند.

نکته: برای مشخص کردن یک آرگومان برای گزینه‌های طولانی، می‌توانید از هر دو ساختار --name=value یا --name value استفاده کنید.

کتابخانه عامل بومی (Native Agent Library) مشخص‌شده را بارگذاری می‌کند. پس از نام کتابخانه، می‌توان فهرستی از گزینه‌های مختص آن کتابخانه را که با کاما جدا شده‌اند استفاده کرد.
•
لینوکس و macOS: اگر گزینه -agentlib:foo مشخص شود، JVM تلاش می‌کند کتابخانه با نام libfoo.so را در مسیر مشخص‌شده توسط متغیر سیستمی LD_LIBRARY_PATH بارگذاری کند (در macOS این متغیر DYLD_LIBRARY_PATH است).
•
ویندوز: اگر گزینه -agentlib:foo مشخص شود، JVM تلاش می‌کند کتابخانه با نام foo.dll را در مسیر مشخص‌شده توسط متغیر سیستمی PATH بارگذاری کند.

مثال زیر نحوه بارگذاری کتابخانه پروتکل اشکال‌زدایی سیمی جاوا (JDWP) و گوش دادن به اتصال سوکت روی پورت 8000 و معلق کردن JVM قبل از بارگذاری کلاس اصلی را نشان می‌دهد:

-agentlib:jdwp=transport=dt_socket,server=y,address=8000

کتابخانه عامل بومی مشخص‌شده با مسیر مطلق را بارگذاری می‌کند. این گزینه معادل -agentlib است اما از مسیر کامل و نام فایل کتابخانه استفاده می‌کند.
فهرستی از دایرکتوری‌ها، آرشیوهای JAR و آرشیوهای ZIP جدا شده با نقطه-ویرگول (;) برای جستجوی فایل‌های کلاس.

مشخص کردن classpath بر هر مقداری از متغیر محیطی CLASSPATH اولویت دارد. اگر گزینه مسیر کلاس استفاده نشود و classpath تنظیم نشده باشد، مسیر کلاس کاربر شامل دایرکتوری جاری (.) خواهد بود.

به‌عنوان یک ویژگی خاص، عنصری از مسیر کلاس که شامل نام پایه ستاره (*) باشد، معادل مشخص کردن فهرستی از تمام فایل‌های موجود در دایرکتوری با پسوند .jar یا .JAR در نظر گرفته می‌شود. برنامه جاوا نمی‌تواند تفاوتی بین این دو روش فراخوانی تشخیص دهد. به‌عنوان مثال، اگر دایرکتوری mydir حاوی a.jar و b.JAR باشد، عنصر مسیر کلاس mydir/* به A.jar:b.JAR بسط داده می‌شود، هرچند ترتیب فایل‌های JAR مشخص نیست. تمام فایل‌های .jar در دایرکتوری مشخص‌شده، حتی فایل‌های پنهان، در فهرست گنجانده می‌شوند. یک ورودی مسیر کلاس شامل ستاره (*) به فهرستی از تمام فایل‌های jar در دایرکتوری جاری بسط می‌یابد. متغیر محیطی CLASSPATH نیز در صورت تعریف، به شکل مشابهی بسط می‌یابد. هرگونه بسط کاراکتر عمومی مسیر کلاس قبل از شروع Java VM رخ می‌دهد. برنامه‌های جاوا هرگز کاراکترهای عمومی بسط‌نیافته را نمی‌بینند مگر از طریق پرس‌وجو از متغیرهای محیطی، مانند فراخوانی System.getenv("CLASSPATH").

می‌تواند در هر جایی از خط فرمان، از جمله درون یک فایل آرگومان، برای جلوگیری از بسط بیشتر @filename استفاده شود. این گزینه بسط فایل‌های آرگومان @ را بعد از این گزینه متوقف می‌کند.
به کلاس‌ها اجازه می‌دهد به قابلیت‌های پیش‌نمایش (Preview Features) [https://docs.oracle.com/en/java/javase/12/language/index.html#JSLAN-GUID-5A82FE0E-0CA4-4F1F-B075-564874FE2823] این نسخه وابسته باشند.
دسترسی بومی (Native access) شامل دسترسی به کد یا داده‌های خارج از محیط زمان اجرای جاوا است. این عمل عموماً ناامن است و در صورت انجام نادرست، ممکن است باعث خرابی JVM یا آسیب دیدن حافظه شود. این گزینه به کدهای موجود در ماژول‌های مشخص‌شده اجازه می‌دهد عملیات دسترسی بومی را بدون صدور هشدار انجام دهند. مقدار module می‌تواند ALL-UNNAMED باشد تا دسترسی بومی به تمام کدهای موجود در مسیر کلاس (class path) مجاز دانسته شود.
-illegal-native-access=parameter
کنترل می‌کند که آیا هنگام انجام عملیات دسترسی بومی توسط کدهای ماژول‌هایی که مجاز دانسته نشده‌اند (توسط گزینه -\nable-native-access)، هشداری صادر شود یا خیر. مقادیر مجاز برای parameter عبارتند از:
عملیات دسترسی بومی غیرمجاز بدون صدور هیچ هشداری مجاز است.
هنگام اولین استفاده از عملیات دسترسی بومی غیرمجاز در هر ماژول، یک هشدار صادر می‌شود. این مقدار پیش‌فرض است.
عملیات دسترسی بومی غیرمجاز مجاز نیست و منجر به پرتاب خطای IllegalCallerException می‌شود.
-nalization=value
کنترل می‌کند که آیا JVM متدهای نهایی‌سازی (finalization) اشیاء را اجرا کند یا خیر. مقدار value می‌تواند enabled یا disabled باشد. به‌طور پیش‌فرض، نهایی‌سازی فعال (enabled) است. غیرفعال کردن نهایی‌سازی با -nalization=disabled می‌تواند به شناسایی کدهایی که به مکانیزم منسوخ‌شده نهایی‌سازی وابسته هستند کمک کند.
فهرستی از دایرکتوری‌ها که با نقطه-ویرگول (;) جدا شده‌اند و هر دایرکتوری شامل ماژول‌ها است.
فهرستی از دایرکتوری‌ها که با نقطه-ویرگول (;) جدا شده‌اند و هر دایرکتوری شامل ماژول‌هایی است که جایگزین ماژول‌های قابل ارتقا در ایمیج زمان اجرا می‌شوند.
ماژول‌های ریشه را برای حل وابستگی علاوه بر ماژول اولیه مشخص می‌کند. module همچنین می‌تواند ALL-DEFAULT، ALL-SYSTEM و ALL-MODULE-PATH باشد.
ماژول‌های قابل مشاهده را فهرست کرده و سپس خارج می‌شود.
ماژول مشخص‌شده را توصیف کرده و سپس خارج می‌شود.
ماشین مجازی (VM) را ایجاد می‌کند اما متد اصلی (main) را اجرا نمی‌کند. این گزینه --dry-run ممکن است برای اعتبارسنجی گزینه‌های خط فرمان مانند پیکربندی سیستم ماژول مفید باشد.
همه ماژول‌ها را اعتبارسنجی کرده و خارج می‌شود. این گزینه برای یافتن تداخل‌ها و سایر خطاهای ماژول‌ها در مسیر ماژول مفید است.
مقدار یک ویژگی سیستمی (System Property) را تنظیم می‌کند. متغیر property رشته‌ای بدون فاصله است که نام ویژگی را مشخص می‌کند. متغیر value رشته‌ای است که مقدار ویژگی را مشخص می‌کند. اگر value شامل فاصله باشد، آن را درون علامت نقل‌قول قرار دهید (مانند -Dfoo="foo bar").
بررسی ادعاها (Assertions) را غیرفعال می‌کند. به‌طور پیش‌فرض، ادعاها در تمام بسته‌ها و کلاس‌ها غیرفعال هستند. بدون آرگومان، -disableassertions (-da) ادعاها را در تمام بسته‌ها و کلاس‌ها غیرفعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، ادعاها در بسته مشخص‌شده و تمام زیربسته‌های آن غیرفعال می‌شوند. اگر آرگومان به سادگی ... باشد، ادعاها در بسته بدون نام در دایرکتوری کاری جاری غیرفعال می‌شوند. با آرگومان classname، ادعاها در کلاس مشخص‌شده غیرفعال می‌شوند.

گزینه -disableassertions (-da) بر تمام بارگذارنده‌های کلاس (Class Loaders) و کلاس‌های سیستمی (که بارگذارنده کلاس ندارند) اعمال می‌شود. یک استثنا برای این قاعده وجود دارد: اگر گزینه بدون آرگومان ارائه شود، بر کلاس‌های سیستمی اعمال نمی‌شود. این امر غیرفعال کردن ادعاها را در تمام کلاس‌ها به جز کلاس‌های سیستمی آسان می‌کند. گزینه -disablesystemassertions به شما امکان می‌دهد ادعاها را در تمام کلاس‌های سیستمی غیرفعال کنید. برای فعال‌سازی صریح ادعاها در بسته‌ها یا کلاس‌های خاص، از گزینه -enableassertions (-ea) استفاده کنید. هر دو گزینه را می‌توان همزمان استفاده کرد. به‌عنوان مثال، برای اجرای برنامه MyClass با ادعاهای فعال در بسته com.wombat.fruitbat (و هر زیربسته‌ای) اما غیرفعال در کلاس com.wombat.fruitbat.Brickbat، از دستور زیر استفاده کنید:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass

ادعاها را در تمام کلاس‌های سیستمی غیرفعال می‌کند.
ادعاها (Assertions) را فعال می‌کند. به‌طور پیش‌فرض، ادعاها در تمام بسته‌ها و کلاس‌ها غیرفعال هستند. بدون آرگومان، -enableassertions (-ea) ادعاها را در تمام بسته‌ها و کلاس‌ها فعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، ادعاها در بسته مشخص‌شده و تمام زیربسته‌های آن فعال می‌شوند. اگر آرگومان به سادگی ... باشد، ادعاها در بسته بدون نام در دایرکتوری کاری جاری فعال می‌شوند. با آرگومان classname، ادعاها در کلاس مشخص‌شده فعال می‌شوند.

گزینه -enableassertions (-ea) بر تمام بارگذارنده‌های کلاس و کلاس‌های سیستمی (که بارگذارنده کلاس ندارند) اعمال می‌شود. یک استثنا برای این قاعده وجود دارد: اگر گزینه بدون آرگومان ارائه شود، بر کلاس‌های سیستمی اعمال نمی‌شود. این امر فعال‌سازی ادعاها را در تمام کلاس‌ها به جز کلاس‌های سیستمی آسان می‌کند. گزینه -enablesystemassertions سوییچ جداگانه‌ای برای فعال‌سازی ادعاها در تمام کلاس‌های سیستمی فراهم می‌کند. برای غیرفعال‌سازی صریح ادعاها در بسته‌ها یا کلاس‌های خاص، از گزینه -disableassertions (-da) استفاده کنید. اگر یک دستور حاوی چندین نمونه از این سوییچ‌ها باشد، آن‌ها به ترتیب، قبل از بارگذاری هر کلاسی پردازش می‌شوند. به‌عنوان مثال، برای اجرای برنامه MyClass با ادعاهای فعال فقط در بسته com.wombat.fruitbat (و هر زیربسته‌ای) اما غیرفعال در کلاس com.wombat.fruitbat.Brickbat، از دستور زیر استفاده کنید:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass

ادعاها را در تمام کلاس‌های سیستمی فعال می‌کند.
پیام راهنما را در جریان خطا (stderr) چاپ می‌کند.
پیام راهنما را در جریان خروجی استاندارد (stdout) چاپ می‌کند.
عامل زبان برنامه‌نویسی جاوا (Java Programming Language Agent) مشخص‌شده را بارگذاری می‌کند. به java.lang.instrument مراجعه کنید.
نسخه محصول را در جریان خروجی چاپ کرده و به اجرای برنامه ادامه می‌دهد.
نسخه محصول را در جریان خطا چاپ کرده و به اجرای برنامه ادامه می‌دهد.
خروجی حل وابستگی‌های ماژول را در زمان راه‌اندازی نمایش می‌دهد.
صفحه اسپلش (Splash Screen) را با تصویر مشخص‌شده توسط imagepath نمایش می‌دهد. تصاویر مقیاس‌بندی‌شده HiDPI به‌طور خودکار پشتیبانی شده و در صورت موجود بودن استفاده می‌شوند. نام فایل تصویر مقیاس‌بندی‌نشده، مانند image.ext، همیشه باید به‌عنوان آرگومان گزینه -splash ارسال شود. مناسب‌ترین تصویر مقیاس‌بندی‌شده ارائه‌شده به‌طور خودکار انتخاب می‌شود.

به‌عنوان مثال، برای نمایش فایل splash.gif از دایرکتوری images هنگام شروع برنامه، از گزینه زیر استفاده کنید:

-splash:images/splash.gif

برای اطلاعات بیشتر به مستندات SplashScreen API مراجعه کنید.

اطلاعات مربوط به هر کلاس بارگذاری‌شده را نمایش می‌دهد.
اطلاعات مربوط به هر رویداد جمع‌آوری زباله (GC) را نمایش می‌دهد.
اطلاعات مربوط به استفاده از متدهای بومی و سایر فعالیت‌های رابط بومی جاوا (JNI) را نمایش می‌دهد.
اطلاعات مربوط به ماژول‌های در حال استفاده را نمایش می‌دهد.
نسخه محصول را در جریان خروجی استاندارد چاپ کرده و خارج می‌شود.
نسخه محصول را در جریان خطا چاپ کرده و خارج می‌شود.
راهنمای گزینه‌های اضافی را در جریان خطا چاپ می‌کند.
راهنمای گزینه‌های اضافی را در جریان خروجی استاندارد چاپ می‌کند.
@argfile
یک یا چند فایل آرگومان با پیشوند @ را مشخص می‌کند که توسط دستور java استفاده می‌شوند. بسیار رایج است که خط فرمان java به دلیل فایل‌های .jar مورد نیاز در classpath بسیار طولانی شود. گزینه @argfile با توانمندسازی راه‌انداز برای بسط محتویات فایل‌های آرگومان پس از بسط شل اما قبل از پردازش آرگومان‌ها، بر محدودیت‌های طول خط فرمان غلبه می‌کند. محتویات درون فایل‌های آرگومان بسط می‌یابند زیرا در غیر این صورت، تا زمانی که گزینه --disable-@files مشاهده شود، روی خط فرمان مشخص می‌شدند.

فایل‌های آرگومان همچنین می‌توانند شامل نام کلاس اصلی و تمام گزینه‌ها باشند. اگر یک فایل آرگومان شامل تمام گزینه‌های مورد نیاز دستور java باشد، خط فرمان می‌تواند به سادگی دستور زیر باشد:

java @argfile

برای توضیحات و مثال‌های استفاده از فایل‌های آرگومان @، به بخش فایل‌های آرگومان خط فرمان جاوا (java Command-Line Argument Files) مراجعه کنید.

گزینه‌های java زیر گزینه‌های عمومی هستند که مختص ماشین مجازی Java HotSpot می‌باشند.

کامپایل در پس‌زمینه را غیرفعال می‌کند. به‌طور پیش‌فرض، JVM متد را به‌عنوان یک تسک پس‌زمینه کامپایل می‌کند و تا زمان اتمام کامپایل پس‌زمینه، متد را در حالت مفسر اجرا می‌کند. پرچم -Xbatch کامپایل پس‌زمینه را غیرفعال می‌کند تا کامپایل تمام متدها به‌عنوان یک تسک پیش‌زمینه تا زمان تکمیل پیش برود. این گزینه معادل -XX:-BackgroundCompilation است.
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را برای اضافه شدن به انتهای مسیر کلاس بوت‌استرپ (Bootstrap Class Path) پیش‌فرض مشخص می‌کند.

لینوکس و macOS: دونقطه (:) موجودیت‌ها را در این فهرست جدا می‌کند.

ویندوز: نقطه-ویرگول (;) موجودیت‌ها را در این فهرست جدا می‌کند.

بررسی‌های اضافی را برای توابع رابط بومی جاوا (JNI) انجام می‌دهد.

بررسی‌های زیر نشان‌دهنده مشکلات قابل توجه در کد بومی تلقی می‌شوند و JVM در چنین مواردی با خطای غیرقابل بازیابی خاتمه می‌یابد:

•
نخی که فراخوانی را انجام می‌دهد به JVM متصل (Attach) نشده است.
•
نخی که فراخوانی را انجام می‌دهد از JNIEnv متعلق به نخ دیگری استفاده می‌کند.
•
یک بررسی اعتبارسنجی پارامتر با شکست مواجه شود:
•
یک jfieldID یا jmethodID نامعتبر تشخیص داده شود. به‌عنوان مثال:
•
از نوع نادرست باشد
•
مرتبط با کلاس نادرست باشد
•
پارامتری با نوع نادرست تشخیص داده شود.
•
مقدار پارامتر نامعتبر تشخیص داده شود. به‌عنوان مثال:
•
مقدار NULL در جایی که مجاز نیست
•
اندیس آرایه خارج از محدوده یا ظرفیت فریم
•
یک رشته غیر UTF-8
•
یک ارجاع JNI نامعتبر
•
تلاش برای استفاده از تابع ReleaseXXX روی پارامتری که توسط تابع متناظر GetXXX تولید نشده است

بررسی‌های زیر تنها منجر به چاپ هشدارهای متنی می‌شوند:

•
یک فراخوانی JNI بدون بررسی استثنای معلق از فراخوانی قبلی JNI انجام شده باشد، و فراخوانی فعلی در صورت وجود استثنای معلق ایمن نباشد.
•
توصیف‌کننده کلاس در قالب تزیین‌شده (Lname;) باشد در حالی که نباید باشد.
•
پارامتر NULL مجاز باشد، اما استفاده از آن جای تردید داشته باشد.
•
فراخوانی سایر توابع JNI در محدوده Get/ReleasePrimitiveArrayCritical یا Get/ReleaseStringCritical

در صورت استفاده از این گزینه، انتظار کاهش کارایی را داشته باشید.

حالت کامپایل اجباری در اولین فراخوانی متدها را فعال می‌کند. این گزینه کامپایلرهای JIT را بلافاصله پس از شروع به کار می‌اندازد و سرعت اجرا را در ابتدا کاهش می‌دهد. این گزینه فقط برای مقاصد آزمایش و اشکال‌زدایی در نظر گرفته شده است.
کاری انجام نمی‌دهد. برای سازگاری با نسخه‌های پیشین فراهم شده است.
پیام‌های تشخیصی اضافی را نمایش می‌دهد.
برنامه را فقط در حالت تفسیری (Interpreted-only) اجرا می‌کند. کامپایل به کد بومی غیرفعال است و تمام بایت‌کدها توسط مفسر اجرا می‌شوند. مزایای کارایی ارائه‌شده توسط کامپایلر Just-In-Time (JIT) در این حالت وجود ندارند.
اطلاعات دقیق‌تری از نسخه JVM نسبت به گزینه -version نمایش داده و سپس خارج می‌شود.
ثبت لاگ را با چارچوب لاگ یکپارچه ماشین مجازی جاوا (JVM) پیکربندی یا فعال می‌کند. به بخش فعال‌سازی لاگ با چارچوب لاگ یکپارچه JVM (Enable Logging with the JVM Unified Logging Framework) مراجعه کنید.
تمام بایت‌کدها را توسط مفسر اجرا می‌کند به جز متدهای داغ (Hot Methods) که به کد بومی کامپایل می‌شوند. به‌طور پیش‌فرض فعال است. برای خاموش کردن از -Xint استفاده کنید.
اندازه اولیه و حداکثر اندازه (به بایت) هیپ برای نسل جوان (Young Generation / Nursery) را در جمع‌آوری‌کننده‌های نسلی تنظیم می‌کند. حرف k یا K را برای نشان دادن کیلوبایت، m یا M برای مگابایت یا g یا G برای گیگابایت اضافه کنید. ناحیه نسل جوان هیپ برای اشیاء جدید استفاده می‌شود. عملیات GC در این ناحیه بیشتر از سایر نواحی انجام می‌شود. اگر اندازه نسل جوان بیش از حد کوچک باشد، تعداد زیادی جمع‌آوری زباله جزئی (Minor GC) انجام می‌شود. اگر اندازه بیش از حد بزرگ باشد، فقط جمع‌آوری‌های کامل زباله (Full GC) انجام می‌شوند که ممکن است زمان زیادی برای تکمیل ببرند. توصیه می‌شود که برای جمع‌آوری‌کننده G1 اندازه نسل جوان را تنظیم نکنید، و برای سایر جمع‌آوری‌کننده‌ها اندازه نسل جوان را بیشتر از 25٪ و کمتر از 50٪ اندازه کل هیپ نگه دارید. مثال‌های زیر نحوه تنظیم اندازه اولیه و حداکثر اندازه نسل جوان روی 256 مگابایت را با واحدهای مختلف نشان می‌دهند:

-Xmn256m
-Xmn262144k
-Xmn268435456

به‌جای گزینه -Xmn برای تنظیم هم‌زمان اندازه اولیه و حداکثر اندازه هیپ برای نسل جوان، می‌توانید از -XX:NewSize برای تنظیم اندازه اولیه و از -XX:MaxNewSize برای تنظیم حداکثر اندازه استفاده کنید.

حداقل و اندازه اولیه (به بایت) هیپ را تنظیم می‌کند. این مقدار باید مضربی از 1024 و بزرگتر از 1 مگابایت باشد. حرف k یا K را برای نشان دادن کیلوبایت، m یا M برای مگابایت یا g یا G برای گیگابایت اضافه کنید. مثال‌های زیر نحوه تنظیم اندازه حافظه تخصیص‌یافته به 6 مگابایت را با واحدهای مختلف نشان می‌دهند:

-Xms6291456
-Xms6144k
-Xms6m

به‌جای گزینه -Xms برای تنظیم هم‌زمان حداقل و اندازه اولیه هیپ، می‌توانید از -XX:MinHeapSize برای تنظیم حداقل اندازه و از -XX:InitialHeapSize برای تنظیم اندازه اولیه استفاده کنید.

اگر این گزینه را تنظیم نکنید، اندازه اولیه برابر با مجموع اندازه‌های تخصیص‌یافته برای نسل قدیم و نسل جوان تنظیم می‌شود. اندازه اولیه هیپ برای نسل جوان را می‌توان با استفاده از گزینه -Xmn یا گزینه -XX:NewSize تنظیم کرد.

حداکثر اندازه (به بایت) هیپ را مشخص می‌کند. این مقدار باید مضربی از 1024 و بزرگتر از 2 مگابایت باشد. حرف k یا K را برای نشان دادن کیلوبایت، m یا M برای مگابایت یا g یا G برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. برای استقرار در سرور، معمولاً -Xms و -Xmx روی مقدار یکسانی تنظیم می‌شوند. مثال‌های زیر نحوه تنظیم حداکثر اندازه مجاز حافظه تخصیص‌یافته به 80 مگابایت را با واحدهای مختلف نشان می‌دهند:

-Xmx83886080
-Xmx81920k
-Xmx80m

گزینه -Xmx معادل -XX:MaxHeapSize است.

جمع‌آوری زباله (GC) کلاس‌ها را غیرفعال می‌کند. این کار می‌تواند مقداری از زمان GC را صرفه‌جویی کند که وقفه‌ها را در طول اجرای برنامه کوتاه می‌کند. وقتی در زمان راه‌اندازی -Xnoclassgc را مشخص می‌کنید، اشیاء کلاس در برنامه در طول GC دست‌نخورده باقی می‌مانند و همیشه زنده در نظر گرفته می‌شوند. این امر می‌تواند منجر به اشغال دائمی حافظه بیشتر شود که اگر با احتیاط استفاده نشود، استثنای کمبود حافظه (Out of Memory) ایجاد می‌کند.
استفاده از سیگنال‌های سیستم‌عامل توسط JVM را کاهش می‌دهد. قلاب‌های خاموشی (Shutdown Hooks) امکان خاموش شدن منظم یک برنامه جاوا را با اجرای کد پاکسازی کاربر (مانند بستن اتصالات پایگاه‌داده) در هنگام خاموش شدن، حتی در صورت پایان ناگهانی JVM فراهم می‌کنند.
•
لینوکس و macOS:
•
ماشین مجازی JVM سیگنال‌ها را برای پیاده‌سازی قلاب‌های خاموشی جهت خاتمه‌های غیرمنتظره دریافت می‌کند. ماشین مجازی JVM از SIGHUP، SIGINT و SIGTERM برای شروع اجرای قلاب‌های خاموشی استفاده می‌کند.
•
برنامه‌هایی که JVM را درون خود تعبیه می‌کنند، مکرراً نیاز به به دام انداختن سیگنال‌هایی مانند SIGINT یا SIGTERM دارند که می‌تواند منجر به تداخل با گرداننده‌های سیگنال JVM شود. گزینه -Xrs برای رفع این مشکل در دسترس است. هنگامی که از -Xrs استفاده می‌شود، ماسک‌های سیگنال برای SIGINT، SIGTERM، SIGHUP و SIGQUIT توسط JVM تغییر نمی‌کنند و گرداننده‌های سیگنال برای این سیگنال‌ها نصب نمی‌شوند.
•
ویندوز:
•
ماشین مجازی JVM رویدادهای کنترلی کنسول را برای پیاده‌سازی قلاب‌های خاموشی جهت خاتمه غیرمنتظره زیر نظر می‌گیرد. به‌طور مشخص، JVM یک گرداننده کنترل کنسول ثبت می‌کند که پردازش قلاب خاموشی را آغاز کرده و برای CTRL_C_EVENT، CTRL_CLOSE_EVENT، CTRL_LOGOFF_EVENT و CTRL_SHUTDOWN_EVENT مقدار TRUE برمی‌گرداند.
•
ماشین مجازی JVM از مکانیزم مشابهی برای پیاده‌سازی قابلیت دامپ استک‌های نخ برای اهداف اشکال‌زدایی استفاده می‌کند. ماشین مجازی JVM از CTRL_BREAK_EVENT برای انجام دامپ نخ استفاده می‌کند.
•
اگر JVM به‌عنوان یک سرویس اجرا شود (به‌عنوان مثال، به‌عنوان یک موتور سرولت برای یک وب‌سرور)، می‌تواند CTRL_LOGOFF_EVENT را دریافت کند اما نباید خاموشی را آغاز کند زیرا سیستم‌عامل در واقع فرایند را خاتمه نمی‌دهد. برای جلوگیری از تداخل احتمالی مانند این، می‌توان از گزینه -Xrs استفاده کرد. هنگامی که از گزینه -Xrs استفاده می‌شود، JVM گرداننده کنترل کنسول را نصب نمی‌کند، به این معنی که رویدادهای CTRL_C_EVENT، CTRL_CLOSE_EVENT، CTRL_LOGOFF_EVENT یا CTRL_SHUTDOWN_EVENT را رصد یا پردازش نمی‌کند.

مشخص کردن -Xrs دو پیامد دارد:

•
لینوکس و macOS: دامپ‌های نخ SIGQUIT در دسترس نیستند.
•
ویندوز: دامپ‌های نخ Ctrl + Break در دسترس نیستند.

کد کاربر مسئول اجرای قلاب‌های خاموشی است، به‌عنوان مثال، با فراخوانی System.exit() در زمانی که قرار است JVM خاتمه یابد.

حالت اشتراک‌گذاری داده‌های کلاس (CDS) را تنظیم می‌کند.

آرگومان‌های ممکن mode برای این گزینه شامل موارد زیر هستند:

در صورت امکان از داده‌های کلاس مشترک استفاده می‌کند (پیش‌فرض).
استفاده از داده‌های کلاس مشترک را الزامی می‌کند، در غیر این صورت با شکست مواجه می‌شود.

نکته: گزینه -Xshare:on فقط برای اهداف آزمایشی استفاده می‌شود. ممکن است باعث شود که ماشین مجازی در هنگام راه‌اندازی، زمانی که آرشیو CDS قابل استفاده نیست (به‌عنوان مثال، زمانی که برخی پارامترهای VM تغییر می‌کنند، یا زمانی که JDK متفاوتی استفاده می‌شود)، به‌طور غیرمنتظره‌ای خارج شود. این گزینه نباید در محیط‌های عملیاتی استفاده شود.

دستور می‌دهد مصرف حافظه بومی JVM ردگیری نشود. این رفتار پیش‌فرض است اگر گزینه -XX:NativeMemoryTracking را مشخص نکنید.
تمام تنظیمات را نمایش داده و سپس به اجرا ادامه می‌دهد.
تنظیمات را نمایش داده و ادامه می‌دهد. آرگومان‌های ممکن category برای این گزینه شامل موارد زیر هستند:
تمام دسته‌بندی‌های تنظیمات را نمایش می‌دهد. این مقدار پیش‌فرض است.
تنظیمات مربوط به محلی‌سازی (Locale) را نمایش می‌دهد.
تنظیمات مربوط به ویژگی‌های سیستمی را نمایش می‌دهد.
تمام تنظیمات مربوط به امنیت را نمایش می‌دهد.
آرگومان‌های زیرمجموعه برای security شامل موارد زیر هستند:
  • security:all : تمام تنظیمات امنیتی را نمایش می‌دهد
  • security:properties : ویژگی‌های امنیتی را نمایش می‌دهد
  • security:providers : تنظیمات ارائه‌دهندگان امنیتی ایستا را نمایش می‌دهد
  • security:tls : تنظیمات TLS را نمایش می‌دهد
تنظیمات JVM را نمایش می‌دهد.
لینوکس: پیکربندی سیستم میزبان یا کانتینر را نمایش داده و ادامه می‌دهد.
اندازه پشته نخ (Thread Stack Size) را به بایت تنظیم می‌کند. حرف k یا K را برای نشان دادن کیلوبایت، m یا M برای مگابایت یا g یا G برای گیگابایت اضافه کنید. مقدار پیش‌فرض به پلتفرم بستگی دارد:
•
لینوکس/x64 (نسخه ۶۴ بیتی): 1024 کیلوبایت
•
مک macOS (نسخه ۶۴ بیتی): 1024 کیلوبایت
•
ویندوز: مقدار پیش‌فرض به حافظه مجازی بستگی دارد

مثال‌های زیر اندازه پشته نخ را با واحدهای مختلف روی 1024 کیلوبایت تنظیم می‌کنند:


-Xss1m
-Xss1024k
-Xss1048576

این گزینه شبیه به -XX:ThreadStackSize است.

ماژول module را برای خواندن target-module، صرف‌نظر از اعلان ماژول، به‌روزرسانی می‌کند. مقدار target-module می‌تواند all unnamed برای خواندن تمام ماژول‌های بدون نام باشد.
ماژول module را برای برون‌ریزی (Export) بسته package به target-module، صرف‌نظر از اعلان ماژول، به‌روزرسانی می‌کند. مقدار target-module می‌تواند all unnamed برای برون‌ریزی به تمام ماژول‌های بدون نام باشد.
ماژول module را برای باز کردن بسته package به روی target-module، صرف‌نظر از اعلان ماژول، به‌روزرسانی می‌کند.
محدوده ماژول‌های قابل مشاهده را مشخص می‌کند.
یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها بازنویسی کرده یا بهبود می‌بخشد.
نسخه سورس‌کد را در حالت فایل سورس تنظیم می‌کند.
استفاده از متدهای دسترسی به حافظه تعریف‌شده در کلاس پشتیبانی‌نشده sun.misc.Unsafe را کنترل می‌کند. مقدار value می‌تواند یکی از موارد زیر باشد:
اجازه استفاده از متدهای دسترسی به حافظه بدون هیچ هشداری در زمان اجرا داده می‌شود.
اجازه استفاده از متدهای دسترسی به حافظه داده می‌شود، اما در اولین باری که از هر یک از متدهای دسترسی به حافظه استفاده شود یک پیام هشدار صادر می‌گردد. حداکثر یک هشدار صادر می‌شود.
اجازه استفاده از متدهای دسترسی به حافظه داده می‌شود، اما با هر بار استفاده از متدهای دسترسی به حافظه یک پیام هشدار یک‌خطی و رد پشته (stack trace) چاپ می‌شود.
عدم اجازه استفاده از متدهای دسترسی به حافظه با پرتاب خطای UnsupportedOperationException در هر بار استفاده. مقدار پیش‌فرض در صورت عدم مشخص کردن این گزینه warn است.

گزینه‌های اضافی زیر مختص سیستم‌عامل macOS هستند.

متد main() را روی نخ اول (AppKit) اجرا می‌کند.
نام پیش‌فرض برنامه نمایش داده‌شده در داک (Dock) را بازنویسی می‌کند.
آیکون پیش‌فرض نمایش داده‌شده در داک را بازنویسی می‌کند.

این گزینه‌های java می‌توانند برای فعال کردن سایر گزینه‌های پیشرفته استفاده شوند.

گزینه‌های در نظر گرفته شده برای عیب‌یابی و تشخیص JVM را بازگشایی می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و گزینه‌های تشخیصی در دسترس نیستند.

گزینه‌های خط فرمانی که با استفاده از این گزینه فعال می‌شوند، پشتیبانی رسمی ندارند. اگر هنگام استفاده از هر یک از این گزینه‌ها با مشکلی مواجه شدید، احتمالاً لازم خواهد بود قبل از دریافت راهنمایی و بررسی از سوی پشتیبانی اوراکل، مشکل را بدون استفاده از این گزینه‌های پشتیبانی‌نشده بازتولید کنید. همچنین این احتمال وجود دارد که هر یک از این گزینه‌ها بدون هیچ هشداری حذف شوند یا رفتار آن‌ها تغییر کند.

گزینه‌هایی را که قابلیت‌های آزمایشی را در JVM فراهم می‌کنند بازگشایی می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و قابلیت‌های آزمایشی در دسترس نیستند.

این گزینه‌های java رفتار زمان اجرای ماشین مجازی Java HotSpot را کنترل می‌کنند.

تعداد پردازنده‌هایی (CPU) را که ماشین مجازی برای محاسبه اندازه استخرهای نخ (Thread Pools) مورد استفاده در عملیات مختلف مانند جمع‌آوری زباله و ForkJoinPool به کار می‌برد، بازنویسی می‌کند.

ماشین مجازی به‌طور معمول تعداد پردازنده‌های موجود را از سیستم‌عامل تعیین می‌کند. این پرچم می‌تواند برای بخش‌بندی منابع CPU هنگام اجرای چندین فرایند جاوا در کانتینرهای داکر مفید باشد. این پرچم حتی اگر UseContainerSupport فعال نباشد نیز اعمال می‌شود. برای توضیحات مربوط به فعال‌سازی و غیرفعال‌سازی پشتیبانی از کانتینر، به -XX:-UseContainerSupport مراجعه کنید.

مسیری به سیستم فایل دریافت کرده و از نگاشت حافظه (Memory Mapping) برای تخصیص هیپ اشیاء بر روی دستگاه حافظه استفاده می‌کند. استفاده از این گزینه HotSpot VM را قادر می‌سازد تا هیپ اشیاء جاوا را بر روی یک دستگاه حافظه جایگزین مانند NV-DIMM که توسط کاربر مشخص شده است تخصیص دهد.

دستگاه‌های حافظه جایگزین که معناشناسی مشابهی با DRAM دارند، از جمله معناشناسی عملیات اتمیک، می‌توانند به جای DRAM برای هیپ اشیاء بدون تغییر کد برنامه موجود استفاده شوند. تمام ساختارهای حافظه دیگر (مانند هیپ کد، متاسپیس و پشته‌های نخ) همچنان در DRAM باقی می‌مانند.

برخی از سیستم‌عامل‌ها حافظه غیر DRAM را از طریق سیستم فایل در معرض دسترسی قرار می‌دهند. فایل‌های نگاشت‌شده در حافظه در این سیستم‌های فایل از کش صفحه (Page Cache) عبور کرده و نگاشت مستقیمی از حافظه مجازی به حافظه فیزیکی روی دستگاه فراهم می‌کنند. پرچم‌های موجود مربوط به هیپ (مانند -Xmx و -Xms) و پرچم‌های مربوط به جمع‌آوری زباله مانند قبل به کار خود ادامه می‌دهند.

قابلیت رشته‌های فشرده (Compact Strings) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است. هنگامی که این گزینه فعال باشد، رشته‌های جاوا که فقط حاوی کاراکترهای تک‌بایتی هستند، به‌صورت داخلی با کدگذاری ISO-8859-1 / Latin-1 به‌صورت یک بایت به ازای هر کاراکتر ذخیره و نمایش داده می‌شوند. این امر فضای مورد نیاز برای رشته‌هایی که فقط حاوی کاراکترهای تک‌بایتی هستند را تا 50٪ کاهش می‌دهد. برای رشته‌های جاوایی که حداقل یک کاراکتر چندبایتی دارند، با کدگذاری UTF-16 به‌صورت 2 بایت به ازای هر کاراکتر نمایش داده و ذخیره می‌شوند. غیرفعال کردن قابلیت رشته‌های فشرده، استفاده از کدگذاری UTF-16 را به‌عنوان نمایش داخلی برای تمام رشته‌های جاوا اجباری می‌کند.

موارد زیر شرایطی هستند که غیرفعال کردن رشته‌های فشرده در آن‌ها می‌تواند مفید باشد:

•
زمانی که مشخص است یک برنامه عمدتاً رشته‌هایی با کاراکترهای چندبایتی تخصیص می‌دهد.
•
در شرایط غیرمنتظره‌ای که افت کارایی در مهاجرت از Java SE 8 به Java SE 9 مشاهده شود و تحلیل‌ها نشان دهند که Compact Strings عامل این افت است.

در هر دوی این سناریوها، غیرفعال کردن Compact Strings منطقی است.

مسیر و نام فایلی را که داده‌های خطا در صورت بروز خطای غیرقابل بازیابی در آن نوشته می‌شوند مشخص می‌کند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری با نام hs_err_pidpid.log ایجاد می‌شود که در آن pid شناسه فرایندی است که با خطا مواجه شده است.

مثال زیر نحوه تنظیم فایل لاگ پیش‌فرض را نشان می‌دهد (توجه داشته باشید که شناسه فرایند به‌صورت %p مشخص شده است):

-XX:ErrorFile=./hs_err_pid%p.log

•
لینوکس و macOS: مثال زیر نحوه تنظیم لاگ خطا روی /var/log/java/java_error.log را نشان می‌دهد:

-XX:ErrorFile=/var/log/java/java_error.log

•
ویندوز: مثال زیر نحوه تنظیم فایل لاگ خطا روی C:/log/java/java_error.log را نشان می‌دهد:

-XX:ErrorFile=C:/log/java/java_error.log

اگر فایل وجود داشته و قابل نوشتن باشد، بازنویسی می‌شود. در غیر این صورت، اگر فایل نتواند در دایرکتوری مشخص‌شده ایجاد شود (به دلیل کمبود فضا، مشکل دسترسی یا موارد دیگر)، فایل در دایرکتوری موقت سیستم‌عامل ایجاد می‌شود:

•
لینوکس و macOS: دایرکتوری موقت /tmp است.
•
ویندوز: دایرکتوری موقت با مقدار متغیر محیطی TMP مشخص می‌شود؛ اگر این متغیر تعریف نشده باشد، مقدار متغیر محیطی TEMP استفاده می‌شود.
گزارش اطلاعات خطای جامع‌تر در ErrorFile را فعال می‌کند. این گزینه می‌تواند در محیط‌هایی که حداکثر اطلاعات مورد نظر است روشن شود - حتی اگر لاگ‌های حاصل بسیار بزرگ باشند یا حاوی اطلاعاتی باشند که حساس تلقی می‌شوند. اطلاعات می‌تواند از نسخه‌ای به نسخه دیگر و در پلتفرم‌های مختلف متفاوت باشد. به‌طور پیش‌فرض این گزینه غیرفعال است.
پارامترهایی را که رفتار JFR (Java Flight Recorder) را کنترل می‌کنند تنظیم می‌کند.

فهرست زیر حاوی ورودی‌های موجود parameter=value برای JFR است:

مقدار کل حافظه اصلی مورد استفاده برای نگهداری داده‌ها را مشخص می‌کند. مقدار پیش‌فرض بر اساس مقدار مشخص‌شده برای memorysize تعیین می‌شود. برای تغییر اندازه بافرهای سراسری، پارامتر memorysize را تغییر دهید.
حداکثر اندازه (به بایت) تکه‌های داده (Data Chunks) در یک ضبط را مشخص می‌کند. حرف m یا M را برای تعیین اندازه به مگابایت (MB) یا g یا G برای تعیین اندازه به گیگابایت (GB) اضافه کنید. به‌طور پیش‌فرض، حداکثر اندازه تکه‌های داده روی 12 مگابایت تنظیم شده است. حداقل مقدار مجاز 1 مگابایت است.
تعیین می‌کند چه مقدار حافظه بافر باید استفاده شود، و پارامترهای globalbuffersize و numglobalbuffers را بر اساس اندازه مشخص‌شده تنظیم می‌کند. حرف m یا M را برای تعیین اندازه به مگابایت (MB) یا g یا G برای تعیین اندازه به گیگابایت (GB) اضافه کنید. به‌طور پیش‌فرض، اندازه حافظه روی 10 مگابایت تنظیم شده است.
تعداد بافرهای سراسری مورد استفاده را مشخص می‌کند. مقدار پیش‌فرض بر اساس اندازه حافظه مشخص‌شده تعیین می‌شود. برای تغییر تعداد بافرهای سراسری، پارامتر memorysize را تغییر دهید.
حداکثر تعداد اشیاء قدیمی برای ردگیری. به‌طور پیش‌فرض، تعداد اشیاء روی 256 تنظیم شده است.
مشخص می‌کند آیا فایل‌های ذخیره‌شده در مخزن دیسک پس از خروج JVM نگهداری شوند یا خیر. اگر false باشد، فایل‌ها حذف می‌شوند. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
مخزن (یک دایرکتوری) را برای ذخیره‌سازی موقت دیسک مشخص می‌کند. به‌طور پیش‌فرض، از دایرکتوری موقت سیستم استفاده می‌شود.
مشخص می‌کند که آیا کلاس‌های رویداد باید با استفاده از JVMTI بازتغییرشکل (Retransform) داده شوند یا خیر. اگر false باشد، ابزارسازی (Instrumentation) هنگام بارگذاری کلاس‌های رویداد اضافه می‌شود. به‌طور پیش‌فرض، این پارامتر فعال است.
عمق پشته برای ردیابی‌های پشته (Stack Traces). به‌طور پیش‌فرض، عمق روی 64 فراخوانی متد تنظیم شده است. حداکثر مقدار 2048 است. مقادیر بزرگتر از 64 می‌توانند بار اضافی قابل توجهی ایجاد کرده و کارایی را کاهش دهند.
اندازه بافر محلی هر نخ (به بایت) را مشخص می‌کند. به‌طور پیش‌فرض، اندازه بافر محلی روی 8 کیلوبایت تنظیم شده و حداقل مقدار آن 4 کیلوبایت است. تغییر این پارامتر می‌تواند کارایی را کاهش دهد و توصیه نمی‌شود.

می‌توانید مقادیر چندین پارامتر را با جدا کردن آن‌ها با کاما مشخص کنید.

حداکثر اندازه صفحه بزرگ حافظه (به بایت) مورد استفاده توسط JVM را تنظیم می‌کند. آرگومان size باید اندازه صفحه معتبری باشد که توسط محیط پشتیبانی می‌شود تا اثربخش باشد. حرف k یا K را برای نشان دادن کیلوبایت، m یا M برای مگابایت یا g یا G برای گیگابایت اضافه کنید. به‌طور پیش‌فرض، اندازه روی 0 تنظیم شده است، به این معنی که JVM از اندازه پیش‌فرض صفحه بزرگ محیط به‌عنوان حداکثر اندازه برای صفحات بزرگ استفاده می‌کند. به بخش صفحات بزرگ حافظه (Large Pages) مراجعه کنید.

مثال زیر نحوه تنظیم اندازه صفحه بزرگ روی 1 گیگابایت (GB) را شرح می‌دهد:

-XX:LargePageSizeInBytes=1g

حداکثر اندازه کل (به بایت) تخصیص‌های بافر مستقیم (Direct-buffer) بسته java.nio را تنظیم می‌کند. حرف k یا K را برای نشان دادن کیلوبایت، m یا M برای مگابایت یا g یا G برای گیگابایت اضافه کنید. به‌طور پیش‌فرض، اندازه روی 0 تنظیم شده است، به این معنی که JVM اندازه را برای تخصیص‌های بافر مستقیم NIO به‌طور خودکار انتخاب می‌کند.

مثال‌های زیر نحوه تنظیم اندازه NIO روی 1024 کیلوبایت را با واحدهای مختلف نشان می‌دهند:


-XX:MaxDirectMemorySize=1m
-XX:MaxDirectMemorySize=1024k
-XX:MaxDirectMemorySize=1048576
تلاش برای تنظیم حد نرم (Soft Limit) تعداد توصیف‌کننده‌های فایل باز به حد سخت (Hard Limit) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه در تمام پلتفرم‌ها فعال است، اما در ویندوز نادیده گرفته می‌شود. تنها زمانی که ممکن است نیاز به غیرفعال کردن این گزینه داشته باشید در Mac OS است، جایی که استفاده از آن حداکثر مقدار 10240 را تحمیل می‌کند که کمتر از حداکثر واقعی سیستم است.
حالت ردگیری مصرف حافظه بومی JVM را مشخص می‌کند. آرگومان‌های ممکن mode برای این گزینه شامل موارد زیر هستند:
دستور می‌دهد مصرف حافظه بومی JVM ردگیری نشود. این رفتار پیش‌فرض است اگر گزینه -XX:NativeMemoryTracking را مشخص نکنید.
مصرف حافظه را فقط توسط زیرسیستم‌های JVM مانند هیپ جاوا، کلاس، کد و نخ ردگیری می‌کند.
علاوه بر ردگیری مصرف حافظه توسط زیرسیستم‌های JVM، مصرف حافظه را بر اساس هر CallSite، ناحیه حافظه مجازی مجزا و نواحی متعهدشده (Committed) آن ردگیری می‌کند.
فاصله زمانی (به میلی‌ثانیه) که در آن JVM هیپ بومی را هرس (Trim) می‌کند. مقادیر کمتر حافظه را مشتاقانه‌تر با هزینه بار پردازشی بیشتر آزاد می‌کنند. مقدار 0 (پیش‌فرض) هرس هیپ بومی را غیرفعال می‌کند. هرس هیپ بومی در یک نخ اختصاصی انجام می‌شود.

این گزینه فقط در لینوکس با کتابخانه استاندارد C گنو (glibc) پشتیبانی می‌شود.

حالت «شبیه‌سازی Client VM» را فعال می‌کند که تنها از کامپایلر C1 JIT، یک CodeCache به میزان ۳۲ مگابایت و جمع‌آوری زباله Serial GC استفاده می‌کند. حداکثر مقدار حافظه‌ای که JVM می‌تواند استفاده کند (که توسط پرچم -XX:MaxRAM=n کنترل می‌شود) به‌طور پیش‌فرض روی ۱ گیگابایت تنظیم می‌گردد. رشته emulated-client به خروجی نسخه java -version افزوده می‌شود تا نشان دهد این حالت فعال است.
تراز حافظه اشیاء جاوا (به بایت) را تنظیم می‌کند. به‌طور پیش‌فرض، این مقدار روی 8 بایت تنظیم شده است. مقدار مشخص‌شده باید توانی از 2 باشد و در محدوده 8 تا 256 (شامل هر دو) قرار گیرد. این گزینه امکان استفاده از اشاره‌گرهای فشرده را با اندازه‌های بزرگ هیپ جاوا فراهم می‌کند.

محدودیت اندازه هیپ به بایت به صورت زیر محاسبه می‌شود:

4GB * ObjectAlignmentInBytes

نکته: با افزایش مقدار تراز، فضای استفاده‌نشده بین اشیاء نیز افزایش می‌یابد. در نتیجه، ممکن است هیچ مزیتی از استفاده از اشاره‌گرهای فشرده با اندازه‌های بزرگ هیپ جاوا به دست نیاورید.

یک دستور سفارشی یا مجموعه‌ای از دستورات جدا شده با نقطه-ویرگول را برای اجرا در صورت بروز خطای غیرقابل بازیابی تنظیم می‌کند. اگر رشته شامل فاصله باشد، باید درون علامت نقل‌قول قرار گیرد.
•
لینوکس و macOS: مثال زیر نشان می‌دهد چگونه گزینه -XX:OnError می‌تواند برای اجرای دستور gcore جهت ایجاد ایمیج core و شروع اشکال‌زدا gdb برای اتصال به فرایند در صورت بروز خطای غیرقابل بازیابی استفاده شود (%p شناسه فرایند جاری را مشخص می‌کند):

-XX:OnError="gcore %p;gdb -p %p"

•
ویندوز: مثال زیر نشان می‌دهد چگونه گزینه -XX:OnError می‌تواند برای اجرای ابزار userdump.exe جهت دریافت کرش دامپ در صورت بروز خطای غیرقابل بازیابی استفاده شود (%p شناسه فرایند جاری را مشخص می‌کند). این مثال فرض می‌کند که مسیر ابزار userdump.exe در متغیر محیطی PATH مشخص شده است:

-XX:OnError="userdump.exe %p"

یک دستور سفارشی یا مجموعه‌ای از دستورات جدا شده با نقطه-ویرگول را برای اجرا در زمان پرتاب اولین استثنای OutOfMemoryError تنظیم می‌کند. اگر رشته شامل فاصله باشد، باید درون علامت نقل‌قول قرار گیرد. برای نمونه‌ای از رشته دستور، به توضیحات گزینه -XX:OnError مراجعه کنید.
چاپ پرچم‌های JVM انتخاب‌شده به‌صورت ارگونومیک را که در خط فرمان ظاهر شده‌اند فعال می‌کند. دانستن مقادیر ارگونومیک تنظیم‌شده توسط JVM، مانند اندازه فضای هیپ و جمع‌آوری‌کننده زباله انتخاب‌شده، می‌تواند مفید باشد. به‌طور پیش‌فرض، این گزینه غیرفعال است و پرچم‌ها چاپ نمی‌شوند.
بین استفاده از ثبات RBP به‌عنوان یک ثبات عمومی (-XX:-PreserveFramePointer) و استفاده از ثبات RBP برای نگهداری اشاره‌گر فریم متد در حال اجرای فعلی (-XX:+PreserveFramePointer) یکی را انتخاب می‌کند. اگر اشاره‌گر فریم در دسترس باشد، ابزارهای پروفایلینگ خارجی (مانند Linux perf) می‌توانند ردیابی‌های پشته دقیق‌تری بسازند.
چاپ داده‌های جمع‌آوری‌شده ردگیری حافظه بومی را در زمان خروج JVM، زمانی که ردگیری حافظه بومی فعال است (به -XX:NativeMemoryTracking مراجعه کنید)، فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و داده‌های ردگیری حافظه بومی چاپ نمی‌شوند.
مسیر و نام فایل آرشیو اشتراک‌گذاری داده‌های کلاس (CDS) را مشخص می‌کند.

به بخش اشتراک‌گذاری داده‌های کلاس برنامه (Application Class Data Sharing) مراجعه کنید.

اگر این گزینه مشخص شود، JVM یک فایل آرشیو CDS را تنها در صورتی بارگذاری می‌کند که بررسی یکپارچگی بر اساس چک‌سام‌های CRC32 را با موفقیت پشت سر بگذارد. هدف از این پرچم بررسی آسیب‌های ناخواسته به فایل‌های آرشیو CDS در حین انتقال یا ذخیره‌سازی است. برای تضمین امنیت و عملکرد صحیح CDS، کاربر باید اطمینان حاصل کند که فایل‌های آرشیو CDS مورد استفاده برنامه‌های جاوا بدون مجوز مناسب قابل تغییر نیستند.
داده‌های اشتراکی اضافی اضافه شده به فایل آرشیو را مشخص می‌کند.
فایل متنی حاوی نام کلاس‌هایی را که باید در آرشیو اشتراک‌گذاری داده‌های کلاس (CDS) ذخیره شوند مشخص می‌کند. این فایل شامل نام کامل یک کلاس در هر خط است، با این تفاوت که اسلش (/) جایگزین نقطه (.) می‌شود. به‌عنوان مثال، برای مشخص کردن کلاس‌های java.lang.Object و hello.Main، یک فایل متنی حاوی دو خط زیر ایجاد کنید:

java/lang/Object
hello/Main

کلاس‌هایی که در این فایل متنی مشخص می‌کنید باید شامل کلاس‌هایی باشند که معمولاً توسط برنامه استفاده می‌شوند. آن‌ها ممکن است شامل هر کلاسی از مسیرهای کلاس برنامه، افزونه یا بوت‌استرپ باشند.

به بخش اشتراک‌گذاری داده‌های کلاس برنامه (Application Class Data Sharing) مراجعه کنید.

چاپ پیام‌های بهبودیافته NullPointerException را فعال می‌کند. هنگامی که یک برنامه استثنای NullPointerException پرتاب می‌کند، این گزینه JVM را قادر می‌سازد تا دستورالعمل‌های بایت‌کد برنامه را تحلیل کند تا دقیقاً مشخص کند کدام ارجاع null است، و منبع را با پیام جزئیات نال شرح می‌دهد. پیام جزئیات نال توسط NullPointerException.getMessage() محاسبه و بازگردانده می‌شود و به‌عنوان پیام استثنا همراه با متد، نام فایل و شماره خط چاپ خواهد شد. به‌طور پیش‌فرض، این گزینه فعال است.
نمایش کادر محاوره را در زمانی که JVM با یک خطای غیرقابل بازیابی مواجه می‌شود فعال می‌کند. این کار از خروج JVM جلوگیری کرده و فرایند را فعال نگه می‌دارد تا بتوانید یک اشکال‌زدا به آن متصل کنید و علت خطا را بررسی نمایید. به‌طور پیش‌فرض، این گزینه غیرفعال است.
یک ضبط JFR را برای برنامه جاوا آغاز می‌کند. این گزینه معادل دستور تشخیصی JFR.start است که ضبط را در زمان اجرا آغاز می‌کند. دستور -XX:StartFlightRecording:help گزینه‌های در دسترس و نمونه خطوط فرمان را چاپ می‌کند. می‌توانید ورودی‌های parameter=value زیر را هنگام شروع ضبط JFR تنظیم کنید:
تأخیر بین زمان راه‌اندازی برنامه جاوا و شروع ضبط را مشخص می‌کند. حرف s را برای تعیین زمان به ثانیه، m برای دقیقه، h برای ساعت یا d برای روز اضافه کنید (به‌عنوان مثال، مشخص کردن 10m به معنی 10 دقیقه است). به‌طور پیش‌فرض هیچ تأخیری وجود ندارد و این پارامتر روی 0 تنظیم شده است.
مشخص می‌کند که آیا داده‌ها در حین ضبط روی دیسک نوشته شوند یا خیر. به‌طور پیش‌فرض، این پارامتر فعال است.
مشخص می‌کند که آیا ضبط در حال اجرا هنگام خاموش شدن JVM دامپ شود یا خیر. اگر فعال باشد و نام فایلی وارد نشده باشد، ضبط در فایلی در دایرکتوری که فرایند در آن شروع شده است نوشته می‌شود. نام فایل یک نام تولیدشده توسط سیستم است که حاوی شناسه فرایند، شناسه ضبط و برچسب زمانی فعلی است، مشابه hotspot-pid-47496-id-1-2018_01_25_19_10_41.jfr. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
مدت زمان ضبط را مشخص می‌کند. حرف s را برای تعیین زمان به ثانیه، m برای دقیقه، h برای ساعت یا d برای روز اضافه کنید (به‌عنوان مثال، مشخص کردن 5h به معنی 5 ساعت است). به‌طور پیش‌فرض، مدت زمان نامحدود است و این پارامتر روی 0 تنظیم شده است.
مسیر و نام فایلی را که ضبط هنگام متوقف شدن در آن نوشته می‌شود مشخص می‌کند، به‌عنوان مثال:
•
recording.jfr
•
/home/user/recordings/recording.jfr
•
c:\recordings\recording.jfr
هم نام و هم شناسه یک ضبط را دریافت می‌کند.
حداکثر سن داده‌های دیسک را برای نگهداری در ضبط مشخص می‌کند. این پارامتر تنها زمانی معتبر است که پارامتر disk روی true تنظیم شده باشد. حرف s را برای تعیین زمان به ثانیه، m برای دقیقه، h برای ساعت یا d برای روز اضافه کنید (به‌عنوان مثال، مشخص کردن 30s به معنی 30 ثانیه است). به‌طور پیش‌فرض، حداکثر سن نامحدود است و این پارامتر روی 0s تنظیم شده است.
حداکثر اندازه (به بایت) داده‌های دیسک را برای نگهداری در ضبط مشخص می‌کند. این پارامتر تنها زمانی معتبر است که پارامتر disk روی true تنظیم شده باشد. این مقدار نباید کمتر از مقدار پارامتر maxchunksize تنظیم‌شده با -XX:FlightRecorderOptions باشد. حرف m یا M را برای تعیین اندازه به مگابایت یا g یا G برای تعیین اندازه به گیگابایت اضافه کنید. به‌طور پیش‌فرض، حداکثر اندازه داده‌های دیسک نامحدود است و این پارامتر روی 0 تنظیم شده است.
مشخص می‌کند که آیا مسیر به ریشه‌های جمع‌آوری زباله (GC Roots) در پایان یک ضبط جمع‌آوری شود یا خیر. به‌طور پیش‌فرض، این پارامتر غیرفعال است.

مسیر به ریشه‌های GC برای یافتن نشت‌های حافظه مفید است، اما جمع‌آوری آن زمان‌بر است. این گزینه را تنها زمانی فعال کنید که ضبطی را برای برنامه‌ای شروع می‌کنید که مشکوک به نشت حافظه است. اگر پارامتر settings روی profile تنظیم شده باشد، ردیابی پشته از جایی که شیء دارای نشت احتمالی در آن تخصیص یافته است در اطلاعات جمع‌آوری‌شده گنجانده می‌شود.

نام نمایی را که هنگام خاموش شدن JVM نمایش داده می‌شود، مشخص می‌کند. برای مشخص کردن بیش از یک نما، پارامتر report-on-exit را تکرار کنید. این گزینه در صورتی که disk روی false تنظیم شده باشد در دسترس نیست. برای فهرستی از نماهای موجود، jfr help view را مشاهده کنید. به‌طور پیش‌فرض، هیچ گزارشی تولید نمی‌شود.
مسیر و نام فایل تنظیمات رویداد (از نوع JFC) را مشخص می‌کند. به‌طور پیش‌فرض، فایل default.jfc استفاده می‌شود که در مسیر JAVA_HOME/lib/jfr قرار دارد. این فایل تنظیمات پیش‌فرض مجموعه‌ای از پیش تعریف‌شده از اطلاعات را با بار اضافی کم جمع‌آوری می‌کند، بنابراین تأثیر حداقلی بر کارایی دارد و می‌تواند با ضبط‌هایی که به‌طور مداوم اجرا می‌شوند استفاده شود.

یک فایل تنظیمات دوم نیز ارائه شده است، profile.jfc، که داده‌های بیشتری نسبت به پیکربندی پیش‌فرض فراهم می‌کند، اما می‌تواند بار اضافی بیشتری داشته و بر کارایی تأثیر بگذارد. از این پیکربندی برای دوره‌های زمانی کوتاه هنگامی که اطلاعات بیشتری مورد نیاز است استفاده کنید.

می‌توانید مقادیر چندین پارامتر را با جدا کردن آن‌ها با کاما مشخص کنید. تنظیمات رویداد و گزینه‌های .jfc را می‌توان با استفاده از ساختار زیر مشخص کرد:

یک گزینه کامپایل JIT را به جای آخرین آرگومان (option) به متد مشخص‌شده ارسال می‌کند. گزینه کامپایل در انتها، پس از نام متد تنظیم می‌شود. برای مثال، جهت فعال کردن گزینه BlockLayoutByFrequency برای متد append() از کلاس StringBuffer، از دستور زیر استفاده کنید:

-XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency

می‌توانید چندین گزینه کامپایل را با کاما یا فاصله جدا کرده و مشخص کنید.

مقدار تنظیم رویداد را برای اصلاح مشخص می‌کند. از قالب: #= استفاده کنید. برای افزودن یک تنظیم رویداد جدید، نام رویداد را با '+' پیشوند دهید.

می‌توانید مقادیر چندین تنظیم رویداد و گزینه‌های .jfc را با جدا کردن آن‌ها با کاما مشخص کنید. در صورت تداخل بین یک پارامتر و یک گزینه .jfc، پارامتر اولویت خواهد داشت. جداکننده فضای خالی را می‌توان برای مقادیر بازه زمانی حذف کرد، مانند 20ms. برای اطلاعات بیشتر در مورد ساختار دستوری تنظیمات، به Javadoc بسته jdk.jfr مراجعه کنید.

اندازه پشته نخ جاوا را (به کیلوبایت) تنظیم می‌کند. استفاده از پسوند مقیاس‌بندی مانند k منجر به مقیاس‌بندی مقدار کیلوبایت می‌شود، بنابراین -XX:ThreadStackSize=1k اندازه پشته نخ جاوا را روی 1024*1024 بایت یا 1 مگابایت تنظیم می‌کند. مقدار پیش‌فرض به پلتفرم بستگی دارد:
•
لینوکس/x64 (نسخه ۶۴ بیتی): 1024 کیلوبایت
•
مک macOS (نسخه ۶۴ بیتی): 1024 کیلوبایت
•
ویندوز: مقدار پیش‌فرض به حافظه مجازی بستگی دارد

مثال‌های زیر نحوه تنظیم اندازه پشته نخ را به 1 مگابایت با واحدهای مختلف نشان می‌دهند:


-XX:ThreadStackSize=1k
-XX:ThreadStackSize=1024

این گزینه شبیه به -Xss است.

هدرهای فشرده اشیاء (compact object headers) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است. فعال‌سازی این گزینه ردپای حافظه در هیپ جاوا را به‌طور میانگین به ازای هر شیء ۴ بایت کاهش می‌دهد و اغلب عملکرد را بهبود می‌بخشد.
این قابلیت تا زمانی که به عنوان یک قابلیت آزمایشی تحت ارزیابی قرار دارد، به‌طور پیش‌فرض غیرفعال باقی می‌ماند.
استفاده از اشاره‌گرهای فشرده (Compressed OOPs) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است و از اشاره‌گرهای فشرده استفاده می‌شود. این کار به‌طور خودکار حداکثر اندازه هیپ جاوا تعیین‌شده به‌صورت ارگونومیک را به حداکثر مقدار حافظه‌ای که می‌تواند توسط اشاره‌گرهای فشرده پوشش داده شود محدود می‌کند. به‌طور پیش‌فرض این محدوده 32 گیگابایت است.

با فعال بودن oops فشرده، ارجاعات اشیاء به جای اشاره‌گرهای 64 بیتی به‌عنوان آفست‌های 32 بیتی نمایش داده می‌شوند که معمولاً کارایی را هنگام اجرای برنامه با اندازه‌های هیپ جاوا کوچکتر از محدوده اشاره‌گر oops فشرده افزایش می‌دهد. این گزینه فقط برای JVMهای 64 بیتی کار می‌کند.

استفاده از اشاره‌گرهای فشرده با اندازه‌های هیپ جاوا بزرگتر از 32 گیگابایت امکان‌پذیر است. به گزینه -XX:ObjectAlignmentInBytes مراجعه کنید.

ماشین مجازی اکنون پشتیبانی خودکار از تشخیص کانتینر را فراهم می‌کند که به VM امکان می‌دهد مقدار حافظه و تعداد پردازنده‌های موجود برای یک فرایند جاوا در حال اجرا در کانتینرهای داکر را تعیین کند. از این اطلاعات برای تخصیص منابع سیستم استفاده می‌کند. این پشتیبانی تنها در پلتفرم‌های لینوکس x64 در دسترس است. در صورت پشتیبانی، مقدار پیش‌فرض برای این پرچم true است و پشتیبانی از کانتینر به‌طور پیش‌فرض فعال است. می‌توان آن را با -XX:-UseContainerSupport غیرفعال کرد.

لاگ یکپارچه (Unified Logging) برای کمک به تشخیص مشکلات مربوط به این پشتیبانی در دسترس است.

از -Xlog:os+container=trace برای حداکثر ثبت لاگ اطلاعات کانتینر استفاده کنید. برای شرح استفاده از لاگ یکپارچه، به بخش فعال‌سازی لاگ با چارچوب لاگ یکپارچه JVM (Enable Logging with the JVM Unified Logging Framework) مراجعه کنید.

استفاده از حافظه صفحات بزرگ (Large Pages) را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و از حافظه صفحات بزرگ استفاده نمی‌شود.

به بخش صفحات بزرگ حافظه (Large Pages) مراجعه کنید.

فقط در لینوکس: استفاده از صفحات بزرگی را که می‌توانند به‌طور پویا رشد کرده یا کوچک شوند فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. ممکن است با صفحات بزرگ شفاف (THP) با مشکلات کارایی مواجه شوید زیرا سیستم‌عامل صفحات دیگر را برای ایجاد صفحات بزرگ جابجا می‌کند؛ این گزینه برای آزمایش و تجربه فراهم شده است.
نصب گرداننده‌های سیگنال توسط برنامه را فعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و برنامه مجاز به نصب گرداننده‌های سیگنال نیست.
به کاربر اجازه می‌دهد گزینه‌های VM را در یک فایل مشخص کند، به‌عنوان مثال، java -XX:VMOptionsFile=/var/my_vm_options HelloWorld.
فقط لینوکس AArch64: حالت حفاظت از انشعاب (branch protection) را مشخص می‌کند. تمامی گزینه‌ها به جز none نیازمند این هستند که VM با قابلیت حفاظت از انشعاب فعال کامپایل شده باشد. علاوه بر این، برای حفاظت کامل، هرگونه کتابخانه بومی ارائه‌شده توسط برنامه نیز باید با فعال بودن حفاظت از انشعاب کامپایل شود.
عدم استفاده از حفاظت از انشعاب. این مقدار پیش‌فرض است.
تمامی حالت‌های حفاظت از انشعاب موجود در پلتفرم فعلی را فعال می‌کند.
حفاظت در برابر حملات مبتنی بر ROP را فعال می‌کند (فقط در پلتفرم AArch64 نسخه 8.3 به بالا).

این گزینه‌های java کامپایلرهای پویا و زمان اجرای درجا (JIT) موجود در HotSpot VM را کنترل می‌کنند.

تعداد خطوطی که باید جلوتر از اشاره‌گر تخصیص نمونه پیش‌واکشی شوند را تعیین می‌کند. به‌طور پیش‌فرض، تعداد خطوط برای پیش‌واکشی روی 1 تنظیم شده است:

-XX:AllocateInstancePrefetchLines=1

اندازه (به بایت) فاصله پیش‌واکشی را برای تخصیص شیء تعیین می‌کند. حافظه‌ای که قرار است با مقدار اشیاء جدید مقداردهی شود، تا این فاصله با شروع از نشانی آخرین شیء تخصیص‌یافته پیش‌واکشی می‌شود. هر ریسه جاوا نقطه تخصیص مخصوص به خود را دارد.

مقادیر منفی نشان می‌دهند که فاصله پیش‌واکشی بر اساس بستر (پلتفرم) انتخاب می‌شود. مقادیر مثبت بایت‌های مورد نظر برای پیش‌واکشی هستند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. مقدار پیش‌فرض روی -1 تنظیم شده است.

مثال زیر نحوه تنظیم فاصله پیش‌واکشی روی 1024 بایت را نشان می‌دهد:

-XX:AllocatePrefetchDistance=1024

دستورالعمل پیش‌واکشی را برای پیش‌واکشی جلوتر از اشاره‌گر تخصیص تعیین می‌کند. مقادیر ممکن از 0 تا 3 هستند. دستورالعمل‌های واقعی پشت این مقادیر به بستر اجرایی بستگی دارند. به‌طور پیش‌فرض، دستورالعمل پیش‌واکشی روی 0 تنظیم شده است:

-XX:AllocatePrefetchInstr=0

تعداد خطوط حافظه پنهان (cache lines) را برای بارگذاری پس از آخرین تخصیص شیء، با استفاده از دستورالعمل‌های پیش‌واکشی تولیدشده در کد کامپایل‌شده تعیین می‌کند. مقدار پیش‌فرض اگر آخرین شیء تخصیص‌یافته یک نمونه باشد 1، و اگر یک آرایه باشد 3 است.

مثال زیر نحوه تنظیم تعداد خطوط حافظه پنهان بارگذاری‌شده روی 5 را نشان می‌دهد:

-XX:AllocatePrefetchLines=5

اندازه گام (به بایت) را برای دستورالعمل‌های پیش‌واکشی متوالی تعیین می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. به‌طور پیش‌فرض، اندازه گام روی 16 بایت تنظیم شده است:

-XX:AllocatePrefetchStepSize=16

سبک کد تولیدشده برای دستورالعمل‌های پیش‌واکشی را تعیین می‌کند. آرگومان style یک عدد صحیح از 0 تا 3 است:
0
دستورالعمل‌های پیش‌واکشی تولید نشوند.
1
دستورالعمل‌های پیش‌واکشی پس از هر تخصیص اجرا شوند. این تنظیم پیش‌فرض است.
2
استفاده از اشاره‌گر واترمارک بلوک تخصیص محلی ریسه (TLAB) برای تعیین زمان اجرای دستورالعمل‌های پیش‌واکشی.
3
تولید یک دستورالعمل پیش‌واکشی به ازای هر خط حافظه پنهان (cache line).
کامپایل در پس‌زمینه را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن کامپایل در پس‌زمینه، -XX:-BackgroundCompilation را مشخص کنید (این کار معادل مشخص کردن -Xbatch است).
تعداد ریسه‌های کامپایلر را برای استفاده در کامپایل تعیین می‌کند. به‌طور پیش‌فرض، تعداد ریسه‌های کامپایلر بسته به تعداد CPUها و حافظه موجود برای کد کامپایل‌شده به‌طور خودکار انتخاب می‌شود. مثال زیر نحوه تنظیم تعداد ریسه‌ها روی 2 را نشان می‌دهد:

-XX:CICompilerCount=2

ایجاد پویای ریسه‌های کامپایلر تا سقف تعیین‌شده توسط -XX:CICompilerCount. این گزینه به‌طور پیش‌فرض فعال است.
یک command (دستور) را برای اجرا روی یک method (متد) مشخص می‌کند. برای مثال، برای مستثنی کردن متد indexOf() از کلاس String از کامپایل شدن، از دستور زیر استفاده کنید:

-XX:CompileCommand=exclude,java/lang/String.indexOf

توجه داشته باشید که نام کامل کلاس، شامل تمام بسته‌ها و زیربسته‌ها که با اسلش (/) جدا شده‌اند، مشخص می‌شود. برای سهولت در عملیات کپی و چسباندن (cut and paste)، می‌توان از فرمت نام متد تولیدشده توسط گزینه‌های -XX:+PrintCompilation و -XX:+LogCompilation نیز استفاده کرد:

-XX:CompileCommand=exclude,java.lang.String::indexOf

اگر متد بدون امضا (signature) مشخص شود، دستور روی تمام متدهای دارای نام مشخص‌شده اعمال می‌شود. با این حال، می‌توانید امضای متد را نیز در فرمت فایل کلاس مشخص کنید. در این حالت، باید آرگومان‌ها را درون علامت نقل‌قول (کوتیشن) قرار دهید، زیرا در غیر این صورت پوسته با نقطه-ویرگول (سمیکالن) به عنوان پایان دستور رفتار می‌کند. برای مثال، اگر می‌خواهید فقط متد indexOf(String) از کلاس String را از کامپایل شدن مستثنی کنید، از دستور زیر استفاده کنید:

-XX:CompileCommand="exclude,java/lang/String.indexOf,(Ljava/lang/String;)I"

همچنین می‌توانید از علامت ستاره (*) به عنوان نویسه عام (wildcard) برای نام‌های کلاس و متد استفاده کنید. برای مثال، جهت مستثنی کردن تمام متدهای indexOf() در تمام کلاس‌ها از کامپایل شدن، از دستور زیر استفاده کنید:

-XX:CompileCommand=exclude,*.indexOf

کاماها و نقطه‌ها نام مستعار برای فاصله‌ها (spaces) هستند، که انتقال دستورات کامپایلر را از طریق پوسته آسان‌تر می‌کنند. می‌توانید با استفاده از فاصله‌ها به عنوان جداکننده و با محصور کردن آرگومان در علامت نقل‌قول، آرگومان‌ها را به -XX:CompileCommand ارسال کنید:

-XX:CompileCommand="exclude java/lang/String indexOf"

توجه داشته باشید که کامپایلر JIT پس از تجزیه دستورات ارسالی در خط فرمان با استفاده از گزینه‌های -XX:CompileCommand، دستورات را از فایل .hotspot_compiler می‌خواند. می‌توانید دستوراتی را به این فایل اضافه کنید یا با استفاده از گزینه -XX:CompileCommandFile فایل متفاوتی را مشخص نمایید.

برای افزودن چندین دستور، یا گزینه -XX:CompileCommand را چندین بار مشخص کنید، یا هر آرگومان را با جداکننده خط جدید (\n) جدا کنید. دستورات زیر در دسترس هستند:

یک نقطه توقف (breakpoint) را هنگام اشکال‌زدایی JVM تنظیم می‌کند تا در ابتدای کامپایل متد مشخص‌شده متوقف شود.
تمام متدها را به جز متد مشخص‌شده از کامپایل مستثنی می‌کند. به عنوان جایگزین، می‌توانید از گزینه -XX:CompileOnly استفاده کنید که به شما امکان مشخص کردن چندین متد را می‌دهد.
از درون‌خطی کردن (inlining) متد مشخص‌شده جلوگیری می‌کند.
متد مشخص‌شده را از کامپایل مستثنی می‌کند.
یک پیام راهنما برای گزینه -XX:CompileCommand چاپ می‌کند.
برای درون‌خطی کردن متد مشخص‌شده تلاش می‌کند.
ثبت وقایع کامپایل (با گزینه -XX:+LogCompilation) را برای همه متدها به جز متد مشخص‌شده مستثنی می‌کند. به‌طور پیش‌فرض، ثبت وقایع برای تمام متدهای کامپایل‌شده انجام می‌شود.
یک گزینه کامپایل JIT را به جای آخرین آرگومان (option) به متد مشخص‌شده ارسال می‌کند. گزینه کامپایل در انتها، پس از نام متد تنظیم می‌شود. برای مثال، جهت فعال کردن گزینه BlockLayoutByFrequency برای متد append() از کلاس StringBuffer، از دستور زیر استفاده کنید:

-XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency

می‌توانید چندین گزینه کامپایل را با کاما یا فاصله جدا کرده و مشخص کنید.

کد اسمبلی تولیدشده را پس از کامپایل متد مشخص‌شده چاپ می‌کند.
دستور می‌دهد که دستورات کامپایل چاپ نشوند. به‌طور پیش‌فرض، دستوراتی که با گزینه -XX:CompileCommand مشخص می‌کنید چاپ می‌شوند؛ برای مثال، اگر متد indexOf() از کلاس String را از کامپایل مستثنی کنید، عبارت زیر در خروجی استاندارد چاپ می‌شود:

CompilerOracle: exclude java/lang/String.indexOf

می‌توانید با مشخص کردن گزینه -XX:CompileCommand=quiet قبل از سایر گزینه‌های -XX:CompileCommand، از این چاپ جلوگیری کنید.

فایلی را که دستورات کامپایلر JIT از آن خوانده می‌شوند تعیین می‌کند. به‌طور پیش‌فرض، فایل .hotspot_compiler برای ذخیره دستورات اجراشده توسط کامپایلر JIT استفاده می‌شود.

هر خط در فایل دستورات، نشان‌دهنده یک دستور، نام کلاس و نام متدی است که دستور برای آن استفاده می‌شود. برای مثال، این خط کد اسمبلی را برای متد toString() از کلاس String چاپ می‌کند:

print java/lang/String toString

اگر از دستوراتی برای اجرای کامپایلر JIT روی متدها استفاده می‌کنید، گزینه -XX:CompileCommand را مشاهده کنید.

دستورالعمل‌ها (directives) را از یک فایل هنگام شروع برنامه به پشته دستورالعمل‌ها اضافه می‌کند. مشاهده کنید: کنترل کامپایلر (Compiler Control) [https://docs.oracle.com/en/java/javase/12/vm/compiler-control1.html#GUID-94AD8194-786A-4F19-BFFF-278F8E237F3A].

گزینه -XX:CompilerDirectivesFile باید همراه با گزینه -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را باز می‌کند، استفاده شود.

پشته دستورالعمل‌ها را هنگام شروع برنامه یا هنگامی که دستورالعمل جدیدی اضافه می‌شود چاپ می‌کند.

گزینه -XX:+CompilerDirectivesPrint باید همراه با گزینه -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را باز می‌کند، استفاده شود.

فهرست متدهایی (جداشده با کاما) را که کامپایل باید به آن‌ها محدود شود تعیین می‌کند. فقط متدهای مشخص‌شده کامپایل می‌شوند. هر متد را با نام کامل کلاس (شامل بسته‌ها و زیربسته‌ها) مشخص کنید. برای مثال، برای کامپایل فقط متد length() از کلاس String و متد size() از کلاس List، از دستور زیر استفاده کنید:

-XX:CompileOnly=java/lang/String.length,java/util/List.size

توجه داشته باشید که نام کامل کلاس، شامل تمام بسته‌ها و زیربسته‌ها که با اسلش (/) جدا شده‌اند، مشخص می‌شود. برای سهولت در عملیات کپی و چسباندن، می‌توان از فرمت نام متد تولیدشده توسط گزینه‌های -XX:+PrintCompilation و -XX:+LogCompilation نیز استفاده کرد:

-XX:CompileOnly=java.lang.String::length,java.util.List::size

اگرچه از نویسه‌های عام (wildcards) پشتیبانی نمی‌شود، اما می‌توانید فقط نام کلاس یا بسته را برای کامپایل تمام متدهای آن کلاس یا بسته مشخص کنید، و همچنین می‌توانید فقط متد را مشخص کنید تا متدهای دارای این نام در هر کلاسی کامپایل شوند:


-XX:CompileOnly=java/lang/String
-XX:CompileOnly=java/lang
-XX:CompileOnly=.length
کنترل یکپارچه‌ای بر اولین کامپایل فراهم می‌کند. این گزینه زمان اولین کامپایل متدها را برای هر دو حالت عملیاتی لایه‌ای (tiered) و غیرلایه‌ای (nontiered) کنترل می‌کند. گزینه CompileThresholdScaling یک مقدار ممیز شناور بین 0 و +Inf دارد و آستانه‌های متناظر با حالت عملیاتی جاری (هم لایه‌ای و هم غیرلایه‌ای) را مقیاس‌بندی می‌کند. تنظیم CompileThresholdScaling روی مقداری کمتر از 1.0 منجر به کامپایل زودهنگام‌تر می‌شود در حالی که مقادیر بزرگتر از 1.0 کامپایل را به تاخیر می‌اندازند. تنظیم CompileThresholdScaling روی 0 معادل غیرفعال کردن کامپایل است.
استفاده از تحلیل گریز (escape analysis) را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تحلیل گریز، -XX:-DoEscapeAnalysis را مشخص کنید.
اندازه اولیه حافظه پنهان کد (code cache) را (به بایت) تعیین می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. مقدار پیش‌فرض به بستر اجرایی بستگی دارد. اندازه اولیه حافظه پنهان کد نباید کمتر از کمینه اندازه صفحه حافظه سیستم باشد. مثال زیر نحوه تنظیم اندازه اولیه حافظه پنهان کد روی 32 کیلوبایت را نشان می‌دهد:

-XX:InitialCodeCacheSize=32k

درون‌خطی‌سازی متدها (method inlining) را فعال می‌کند. این گزینه برای افزایش کارایی به‌طور پیش‌فرض فعال است. برای غیرفعال کردن درون‌خطی‌سازی متدها، -XX:-Inline را مشخص کنید.
حداکثر اندازه کد (به بایت) را برای متدهای از قبل کامپایل‌شده که ممکن است درون‌خطی شوند، تعیین می‌کند. این فلگ فقط برای کامپایلر C2 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. مقدار پیش‌فرض به بستر اجرایی و اینکه آیا کامپایل لایه‌ای فعال است یا خیر بستگی دارد. در مثال زیر روی 1000 بایت تنظیم شده است:

-XX:InlineSmallCode=1000

ثبت وقایع فعالیت‌های کامپایل را در فایلی به نام hotspot.log در دایرکتوری کاری جاری فعال می‌کند. می‌توانید با استفاده از گزینه -XX:LogFile مسیر و نام متفاوتی برای فایل لاگ مشخص کنید.

به‌طور پیش‌فرض، این گزینه غیرفعال است و فعالیت کامپایل ثبت نمی‌شود. گزینه -XX:+LogCompilation باید همراه با گزینه -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را باز می‌کند، استفاده شود.

می‌توانید با استفاده از گزینه -XX:+PrintCompilation، خروجی تشخیصی با جزئیات را با پیامی که در هر بار کامپایل یک متد در کنسول چاپ می‌شود فعال کنید.

حداکثر اندازه بایت‌کد (به بایت) یک متد پرکاربرد (hot method) را برای درون‌خطی شدن تعیین می‌کند. این فلگ فقط برای کامپایلر C2 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. مقدار پیش‌فرض به بستر اجرایی بستگی دارد. در مثال زیر روی 325 بایت تنظیم شده است:

-XX:FreqInlineSize=325

حداکثر اندازه بایت‌کد (به بایت) یک متد کم‌کاربرد (cold method) را برای درون‌خطی شدن تعیین می‌کند. این فلگ فقط برای کامپایلر C2 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. به‌طور پیش‌فرض، حداکثر اندازه بایت‌کد روی 35 بایت تنظیم شده است:

-XX:MaxInlineSize=35

حداکثر اندازه بایت‌کد (به بایت) یک متد کم‌کاربرد را برای درون‌خطی شدن تعیین می‌کند. این فلگ فقط برای کامپایلر C1 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. به‌طور پیش‌فرض، حداکثر اندازه بایت‌کد روی 35 بایت تنظیم شده است:

-XX:MaxInlineSize=35

حداکثر اندازه بایت‌کد (به بایت) یک متد جزئی و ساده (trivial method) را برای درون‌خطی شدن تعیین می‌کند. این فلگ فقط برای کامپایلر C2 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. به‌طور پیش‌فرض، حداکثر اندازه بایت‌کد یک متد جزئی روی 6 بایت تنظیم شده است:

-XX:MaxTrivialSize=6

حداکثر اندازه بایت‌کد (به بایت) یک متد جزئی و ساده را برای درون‌خطی شدن تعیین می‌کند. این فلگ فقط برای کامپایلر C1 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. به‌طور پیش‌فرض، حداکثر اندازه بایت‌کد یک متد جزئی روی 6 بایت تنظیم شده است:

-XX:MaxTrivialSize=6

حداکثر تعداد گره‌هایی را که در طول کامپایل یک متد منفرد استفاده می‌شوند تعیین می‌کند. به‌طور پیش‌فرض این مقدار به قابلیت‌های فعال‌شده بستگی دارد. در مثال زیر حداکثر تعداد گره‌ها روی 100,000 تنظیم شده است:

-XX:MaxNodeLimit=100000

اندازه (به بایت) بخش کدی شامل کدهای غیرمتد (nonmethod code) را تعیین می‌کند.

یک بخش کد غیرمتد شامل کدهایی مانند بافرهای کامپایلر و مفسر بایت‌کد است. این نوع کد برای همیشه در حافظه پنهان کد باقی می‌ماند. این فلگ فقط در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.

اندازه (به بایت) بخش کدی شامل متدهای پروفایل‌نشده (nonprofiled) را تعیین می‌کند. این فلگ فقط در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.
بهینه‌سازی عملیات الحاق (concatenation) رشته String را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن بهینه‌سازی عملیات الحاق String، -XX:-OptimizeStringConcat را مشخص کنید.
چاپ کد اسمبلی را برای متدهای بایت‌کدی و بومی (native) با استفاده از کتابخانه خارجی hsdis-<arch>.so یا .dll فعال می‌کند. برای ماشین مجازی 64 بیتی در ویندوز، این کتابخانه hsdis-amd64.dll است. این گزینه به شما امکان می‌دهد کد تولیدشده را مشاهده کنید، که ممکن است به شما در عیب‌یابی مشکلات کارایی کمک کند.

به‌طور پیش‌فرض، این گزینه غیرفعال است و کد اسمبلی چاپ نمی‌شود. گزینه -XX:+PrintAssembly باید همراه با گزینه -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را باز می‌کند، استفاده شود.

اندازه (به بایت) بخش کدی شامل متدهای پروفایل‌شده (profiled) را تعیین می‌کند. این فلگ فقط در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.
خروجی تشخیصی پرجزئیات از JVM را با چاپ پیامی در کنسول در هر بار کامپایل یک متد فعال می‌کند. این گزینه به شما امکان می‌دهد ببینید کدام متدها واقعاً کامپایل می‌شوند. به‌طور پیش‌فرض، این گزینه غیرفعال است و خروجی تشخیصی چاپ نمی‌شود.

همچنین می‌توانید فعالیت کامپایل را با استفاده از گزینه -XX:+LogCompilation در یک فایل ثبت کنید.

چاپ تصمیمات مربوط به درون‌خطی‌سازی (inlining) را فعال می‌کند. این گزینه به شما امکان می‌دهد ببینید کدام متدها درون‌خطی می‌شوند.

به‌طور پیش‌فرض، این گزینه غیرفعال است و اطلاعات درون‌خطی‌سازی چاپ نمی‌شود. گزینه -XX:+PrintInlining باید همراه با گزینه -XX:+UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را باز می‌کند، استفاده شود.

حداکثر اندازه حافظه پنهان کد (به بایت) را برای کدهای کامپایل‌شده توسط JIT تعیین می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت ضمیمه کنید. حداکثر اندازه پیش‌فرض حافظه پنهان کد 240 مگابایت است؛ اگر کامپایل لایه‌ای را با گزینه -XX:-TieredCompilation غیرفعال کنید، اندازه پیش‌فرض 48 مگابایت خواهد بود. این گزینه دارای سقف 2 گیگابایت است؛ در غیر این صورت، خطا ایجاد می‌شود. حداکثر اندازه حافظه پنهان کد نباید کمتر از اندازه اولیه آن باشد؛ گزینه -XX:InitialCodeCacheSize را ببینید.
تقسیم‌بندی حافظه پنهان کد (code cache segmentation) را فعال می‌کند. بدون -XX:+SegmentedCodeCache، حافظه پنهان کد از یک بخش بزرگ تشکیل شده است. با -XX:+SegmentedCodeCache، بخش‌های جداگانه‌ای برای کدهای غیرمتد، متدهای پروفایل‌شده و متدهای پروفایل‌نشده داریم. اندازه این بخش‌ها در زمان اجرا تغییر نمی‌کند. اگر کامپایل لایه‌ای فعال باشد (-XX:+TieredCompilation) و -XX:ReservedCodeCacheSize >= 240 MB باشد، این قابلیت به‌طور پیش‌فرض فعال است. مزایای آن کنترل بهتر ردپای حافظه، کاهش تکه‌تکه شدن کد (fragmentation) و رفتار بهتر iTLB/iCache به دلیل بهبود محلی‌سازی (locality) است. عبارت iTLB/iCache اصطلاحی مخصوص CPU است که به معنای بافر ترجمه نگاه به کنار دستورالعمل (ITLB) است. عبارت ICache حافظه پنهان دستورالعمل در CPU است. پیاده‌سازی حافظه پنهان کد را می‌توانید در فایل زیر بیابید: /share/vm/code/codeCache.cpp.
هنگامی که فقط درصد مشخص‌شده‌ای از حافظه پنهان کد آزاد است، پیمایش پشته متدهای فعال را برای حذف تهاجمی کدهای استفاده‌نشده تحمیل می‌کند. مقدار پیش‌فرض 10% است.
استفاده از کامپایل لایه‌ای (tiered compilation) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه فعال است.
استفاده از مجموعه دستورالعمل‌های SSE با نگارش مشخص‌شده را فعال می‌کند. به‌طور پیش‌فرض روی بالاترین نگارش پشتیبانی‌شده موجود تنظیم است (فقط x86).
استفاده از مجموعه دستورالعمل‌های AVX با نگارش مشخص‌شده را فعال می‌کند. به‌طور پیش‌فرض روی بالاترین نگارش پشتیبانی‌شده موجود تنظیم است (فقط x86).
توابع درونی (intrinsics) رمزنگاری AES مبتنی بر سخت‌افزار را برای سخت‌افزارهایی که از آن پشتیبانی می‌کنند فعال می‌کند. این گزینه در سخت‌افزارهایی که دستورالعمل‌های لازم را دارند به‌طور پیش‌فرض روشن است. گزینه -XX:+UseAES در ترکیب با UseAESIntrinsics استفاده می‌شود. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
توابع درونی AES را فعال می‌کند. مشخص کردن -XX:+UseAESIntrinsics معادل فعال کردن -XX:+UseAES نیز هست. برای غیرفعال کردن توابع درونی AES مبتنی بر سخت‌افزار، -XX:-UseAES -XX:-UseAESIntrinsics را مشخص کنید. برای مثال، جهت فعال کردن AES سخت‌افزاری، از فلگ‌های زیر استفاده کنید:

-XX:+UseAES -XX:+UseAESIntrinsics

فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.

مشابه با -XX:+UseAESIntrinsics توابع درونی AES/CTR را فعال می‌کند.
استفاده از توابع درونی GHASH را کنترل می‌کند. به‌طور پیش‌فرض در بسترهایی که از دستورالعمل‌های مربوطه پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
بهینه‌سازی‌های ذاتی (intrinsics) برای الگوریتم ChaCha20 را فعال می‌کند. این گزینه به‌طور پیش‌فرض برای پلتفرم‌های پشتیبانی‌شده فعال است. برای غیرفعال کردن بهینه‌سازی‌های ChaCha20، گزینه -XX:-UseChaCha20Intrinsics را مشخص کنید. پرچم‌های کنترل‌کننده بهینه‌سازی‌های ذاتی اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
بهینه‌سازی‌های ذاتی (intrinsics) برای الگوریتم Poly1305 را فعال می‌کند. این گزینه به‌طور پیش‌فرض برای پلتفرم‌های پشتیبانی‌شده فعال است. برای غیرفعال کردن بهینه‌سازی‌های Poly1305، گزینه -XX:-UsePoly1305Intrinsics را مشخص کنید. پرچم‌های کنترل‌کننده بهینه‌سازی‌های ذاتی اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از روال‌های شتاب‌یافته رمزگذاری BASE64 را برای java.util.Base64 کنترل می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از تابع درونی الگوریتم چکسام Adler32 را برای java.util.zip.Adler32 کنترل می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از توابع درونی CRC32 را برای java.util.zip.CRC32 کنترل می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
استفاده از توابع درونی CRC32C را برای java.util.zip.CRC32C کنترل می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
توابع درونی مبتنی بر سخت‌افزار را برای توابع درهم‌سازی رمزنگاری SHA در برخی سخت‌افزارها فعال می‌کند. گزینه UseSHA در ترکیب با گزینه‌های UseSHA1Intrinsics، UseSHA256Intrinsics و UseSHA512Intrinsics استفاده می‌شود.

فلگ‌های UseSHA و UseSHA*Intrinsics به‌طور پیش‌فرض روی ماشین‌هایی که از دستورالعمل‌های مربوطه پشتیبانی می‌کنند فعال هستند.

این قابلیت تنها هنگام استفاده از ارائه‌دهنده sun.security.provider.Sun برای عملیات SHA قابل اعمال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.

برای غیرفعال کردن تمام توابع درونی SHA مبتنی بر سخت‌افزار، -XX:-UseSHA را مشخص کنید. برای غیرفعال کردن تنها یک تابع درونی خاص SHA، از گزینه متناظر مناسب استفاده کنید. برای مثال: -XX:-UseSHA256Intrinsics.

توابع درونی را برای تابع درهم‌سازی رمزنگاری SHA-1 فعال می‌کند. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
توابع درونی را برای توابع درهم‌سازی رمزنگاری SHA-224 و SHA-256 فعال می‌کند. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
توابع درونی را برای توابع درهم‌سازی رمزنگاری SHA-384 و SHA-512 فعال می‌کند. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
درونی‌سازی (intrinsification) توابع مختلف java.lang.Math.*Exact() را فعال می‌کند. به‌طور پیش‌فرض فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
درونی‌سازی BigInteger.multiplyToLen() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
درونی‌سازی BigInteger.squareToLen() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
درونی‌سازی BigInteger.mulAdd() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
درونی‌سازی BigInteger.montgomeryMultiply() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
درونی‌سازی BigInteger.montgomerySquare() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. فلگ‌هایی که توابع درونی را کنترل می‌کنند اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
دستورالعمل‌های CMove (اسکالر و برداری) را بدون توجه به تحلیل سودآوری تولید می‌کند.
تخلیه (flush) حافظه پنهان کد را پیش از خاموش کردن کامپایلر فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تخلیه حافظه پنهان کد پیش از خاموش کردن کامپایلر، -XX:-UseCodeCacheFlushing را مشخص کنید.
بررسی اینکه آیا کارت از قبل علامت‌گذاری شده است یا خیر را پیش از به‌روزرسانی جدول کارت‌ها فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. این گزینه باید تنها در ماشین‌های دارای چندین سوکت استفاده شود، جایی که کارایی برنامه‌های کاربردی جاوای متکی بر عملیات همزمان را افزایش می‌دهد.
نقاط امن (safepoints) را در حلقه‌های شمارش‌شده حفظ می‌کند. مقدار پیش‌فرض آن به این بستگی دارد که آیا جمع‌آوری‌کننده زباله انتخاب‌شده به نقاط امن با تاخیر کم نیاز دارد یا خیر.
تعداد تکرارها را در حلقه داخلی استخراج نواری (strip mined) کنترل می‌کند. استخراج نواری حلقه‌های شمارش‌شده را به حلقه‌های تو در توی دو سطحی تبدیل می‌کند. نقاط امن در حلقه بیرونی نگه داشته می‌شوند در حالی که حلقه داخلی می‌تواند با سرعت کامل اجرا شود. این گزینه حداکثر تعداد تکرارها در حلقه داخلی را کنترل می‌کند. مقدار پیش‌فرض 1,000 است.
بهینه‌سازی استخراج نواری حلقه را کنترل می‌کند. حلقه‌هایی با تعداد تکرار کمتر از مقدار مشخص‌شده، نقطه امن در خود نخواهند داشت. مقدار پیش‌فرض یک‌دهم (1/10) مقدار -XX:LoopStripMiningIter است.
توابع درونی FMA مبتنی بر سخت‌افزار را برای سخت‌افزارهایی که دستورالعمل‌های FMA در آن‌ها در دسترس است (مانند Intel و ARM64) فعال می‌کند. توابع درونی FMA برای متدهای java.lang.Math.fma(a, b, c) تولید می‌شوند که مقدار عبارت‌های (a * b + c) را محاسبه می‌کنند.
تبدیل عملیات اسکالر به عملیات ابرکلمه (superword) را فعال می‌کند. ابرکلمه یک بهینه‌سازی برداری‌سازی (vectorization) است. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تبدیل عملیات اسکالر به عملیات ابرکلمه، -XX:-UseSuperWord را مشخص کنید.

این گزینه‌های java امکان جمع‌آوری داده‌های سیستمی و عیب‌یابی دقیق‌تر را فراهم می‌کنند.

مکانیزمی را که به ابزارها امکان اتصال به JVM را می‌دهد، غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است؛ به این معنی که مکانیزم اتصال فعال است و می‌توانید از ابزارهای عیب‌یابی و خطایابی مانند jcmd، jstack، jmap و jinfo استفاده کنید.

نکته: ابزارهایی مانند jcmd، jinfo، jmap و jstack که همراه با JDK عرضه می‌شوند، هنگام استفاده از ابزارهای یک نسخه JDK برای عیب‌یابی نسخه‌ای متفاوت از JDK پشتیبانی نمی‌شوند.

لینوکس و macOS: پروب‌های ابزار dtrace را برای تخصیص شیء فعال می‌کند.
لینوکس و macOS: پروب‌های ابزار dtrace را برای ورود و خروج متد فعال می‌کند.
لینوکس و macOS: پروب‌های ابزار dtrace را برای رویدادهای مانیتور فعال می‌کند.
تخلیه حافظه هیپ (heap dump) جاوا در فایلی در دایرکتوری جاری را با استفاده از پروفایلر هیپ (HPROF) هنگام رخ دادن استثنای java.lang.OutOfMemoryError فعال می‌کند. می‌توانید مسیر و نام فایل دامپ هیپ را با استفاده از گزینه -XX:HeapDumpPath صریحاً تعیین کنید. به‌طور پیش‌فرض، این گزینه غیرفعال است و هنگام رخ دادن استثنای OutOfMemoryError، هیپ دامپ نمی‌شود.
مسیر و نام فایل را برای نوشتن دامپ هیپ ارائه‌شده توسط پروفایلر هیپ (HPROF) هنگامی که گزینه -XX:+HeapDumpOnOutOfMemoryError تنظیم شده است، مشخص می‌کند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری ایجاد شده و java_pid<pid>.hprof نام‌گذاری می‌شود که در آن <pid> شناسه فرایندی است که موجب خطا شده است. مثال زیر نحوه تنظیم صریح فایل پیش‌فرض را نشان می‌دهد (%p نشان‌دهنده شناسه فرایند جاری است):

-XX:HeapDumpPath=./java_pid%p.hprof

•
لینوکس و macOS: مثال زیر نحوه تنظیم فایل دامپ هیپ روی /var/log/java/java_heapdump.hprof را نشان می‌دهد:

-XX:HeapDumpPath=/var/log/java/java_heapdump.hprof

•
ویندوز: مثال زیر نحوه تنظیم فایل دامپ هیپ روی C:/log/java/java_heapdump.log را نشان می‌دهد:

-XX:HeapDumpPath=C:/log/java/java_heapdump.log

مسیر و نام فایل محل نوشتن داده‌های گزارش (log) را تعیین می‌کند. به‌طور پیش‌فرض، فایل در دایرکتوری کاری جاری ایجاد شده و hotspot.log نامیده می‌شود.
•
لینوکس و macOS: مثال زیر نحوه تنظیم فایل لاگ روی /var/log/java/hotspot.log را نشان می‌دهد:

-XX:LogFile=/var/log/java/hotspot.log

•
ویندوز: مثال زیر نحوه تنظیم فایل لاگ روی C:/log/java/hotspot.log را نشان می‌دهد:

-XX:LogFile=C:/log/java/hotspot.log

چاپ هیستوگرام نمونه‌های کلاس را پس از یکی از رویدادهای زیر فعال می‌کند:
•
لینوکس و macOS: کلیدهای ترکیبی Control+Break
•
ویندوز: کلیدهای ترکیبی Control+C (SIGTERM)

به‌طور پیش‌فرض، این گزینه غیرفعال است.

تنظیم این گزینه معادل اجرای دستور jmap -histo یا دستور jcmd pid GC.class_histogram است، که در آن pid شناسه فرایند جاوا جاری است.

چاپ قفل‌های java.util.concurrent را پس از یکی از رویدادهای زیر فعال می‌کند:
•
لینوکس و macOS: کلیدهای ترکیبی Control+Break
•
ویندوز: کلیدهای ترکیبی Control+C (SIGTERM)

به‌طور پیش‌فرض، این گزینه غیرفعال است.

تنظیم این گزینه معادل اجرای دستور jstack -l یا دستور jcmd pid Thread.print -l است، که در آن pid شناسه فرایند جاوا جاری است.

محدوده مشخص‌شده را چاپ کرده و امکان آزمایش خودکار مقادیر را فراهم می‌سازد. بخش اعتبارسنجی آرگومان‌های فلگ ماشین مجازی جاوا (Validate Java Virtual Machine Flag Arguments) را ببینید.
در صورت فعال بودن، هنگام خروج برنامه جاوا، داده‌های باینری jstat را ذخیره می‌کند. این داده‌های باینری در فایلی با نام hsperfdata_pid ذخیره می‌شوند که در آن pid شناسه فرایند برنامه جاوای اجرا شده است. از دستور jstat برای نمایش داده‌های عملکردی موجود در این فایل به‌صورت زیر استفاده کنید:

jstat -class file:///path/hsperfdata_pid

jstat -gc file:///path/hsperfdata_pid

ویژگی perfdata را فعال می‌کند. این گزینه به‌طور پیش‌فرض برای امکان مانیتورینگ JVM و تست عملکرد فعال است. غیرفعال کردن آن مانع از ایجاد دایرکتوری‌های hsperfdata_userid می‌شود. برای غیرفعال کردن ویژگی perfdata، گزینه -XX:-UsePerfData را مشخص کنید.

این گزینه‌های java نحوه مدیریت حافظه و رفتار جمع‌آوری زباله (Garbage Collection) را در Java HotSpot VM کنترل می‌کنند.

بهینه‌سازی هیپ جاوا را فعال می‌کند. این گزینه بر اساس پیکربندی رایانه (رم و پردازنده)، پارامترهای مختلفی را برای کارهای طولانی‌مدت با تخصیص حافظه فشرده بهینه می‌سازد. به‌طور پیش‌فرض، این گزینه غیرفعال است و اندازه‌های هیپ کمتر تهاجمی پیکربندی می‌شوند.
از VM درخواست می‌کند تا تمام صفحات حافظه هیپ جاوا را پس از درخواست از سیستم‌عامل و قبل از تحویل حافظه به برنامه، لمس (touch) کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و تمام صفحات هم‌زمان با استفاده برنامه از فضای هیپ، تثبیت (commit) می‌شوند.
تعداد رشته‌های (threads) مورد استفاده برای GC هم‌روند را تعیین می‌کند. مقدار threads را تقریباً برابر با ۱/۴ تعداد رشته‌های موازی جمع‌آوری زباله قرار می‌دهد. مقدار پیش‌فرض به تعداد پردازنده‌های در دسترس JVM بستگی دارد.

به‌عنوان مثال، برای تنظیم تعداد رشته‌ها برای GC هم‌روند روی ۲، گزینه زیر را مشخص کنید:

-XX:ConcGCThreads=2

گزینه‌ای را که پردازش فراخوانی‌های متد System.gc() را غیرفعال می‌کند، فعال می‌سازد. این گزینه به‌طور پیش‌فرض غیرفعال است، به این معنی که فراخوانی‌های System.gc() پردازش می‌شوند. اگر پردازش فراخوانی‌های System.gc() غیرفعال باشد، JVM همچنان در صورت لزوم GC را انجام می‌دهد.
فراخوانی GC هم‌روند را با استفاده از درخواست System.gc() فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است و فقط همراه با گزینه -XX:+UseG1GC می‌تواند فعال شود.
هنگامی که -XX:UseAdaptiveIHOP فعال باشد، این گزینه تعداد چرخه‌های نشانه‌گذاری (marking) تکمیل‌شده را برای جمع‌آوری نمونه‌ها تعیین می‌کند تا زمانی که G1 به‌صورت تطبیقی مقدار بهینه -XX:InitiatingHeapOccupancyPercent را تعیین کند. پیش از آن، G1 مستقیماً از مقدار -XX:InitiatingHeapOccupancyPercent برای این منظور استفاده می‌کند. مقدار پیش‌فرض ۳ است.
اندازه ناحیه‌هایی (regions) را تعیین می‌کند که حافظه هیپ جاوا هنگام استفاده از جمع‌آورنده اولویت زباله (G1) به آن‌ها تقسیم می‌شود. مقدار باید توانی از ۲ باشد و می‌تواند از ۱ مگابایت تا ۳۲ مگابایت متغیر باشد. اندازه پیش‌فرض ناحیه به‌صورت ارگونومیک بر اساس اندازه هیپ و با هدف دستیابی به حدود ۲۰۴۸ ناحیه تعیین می‌شود.

مثال زیر اندازه زیربخش‌ها را روی ۱۶ مگابایت تنظیم می‌کند:

-XX:G1HeapRegionSize=16m

درصدی از هیپ را که مایل به هدر دادن آن هستید تعیین می‌کند. هنگامی که درصد قابل‌بازیابی کمتر از درصد هدررفت هیپ باشد، Java HotSpot VM چرخه جمع‌آوری زباله ترکیبی (mixed GC) را آغاز نمی‌کند. مقدار پیش‌فرض ۵ درصد است.
درصدی از اندازه هیپ را برای استفاده به‌عنوان بیشینه اندازه نسل جوان (young generation) تعیین می‌کند. مقدار پیش‌فرض ۶۰ درصد از هیپ جاوا است.

این یک فلگ آزمایشی است. این تنظیم جایگزین تنظیم -XX:DefaultMaxNewGenPercent می‌شود.

تعداد هدف جمع‌آوری‌های زباله ترکیبی را پس از یک چرخه نشانه‌گذاری برای جمع‌آوری ناحیه‌های قدیمی با حداکثر داده زنده به میزان G1MixedGCLiveThresholdPercent تعیین می‌کند. مقدار پیش‌فرض ۸ بار جمع‌آوری زباله ترکیبی است. هدف برای جمع‌آوری‌های ترکیبی، ماندن در محدوده این تعداد است.
آستانه اشغال را برای یک ناحیه قدیمی تعیین می‌کند تا در چرخه جمع‌آوری زباله ترکیبی گنجانده شود. اشغال پیش‌فرض ۸۵ درصد است.

این یک فلگ آزمایشی است. این تنظیم جایگزین تنظیم -XX:G1OldCSetRegionLiveThresholdPercent می‌شود.

درصدی از هیپ را برای استفاده به‌عنوان کمینه اندازه نسل جوان تعیین می‌کند. مقدار پیش‌فرض ۵ درصد از هیپ جاوا است.

این یک فلگ آزمایشی است. این تنظیم جایگزین تنظیم -XX:DefaultMinNewGenPercent می‌شود.

حد بالایی را برای تعداد ناحیه‌های قدیمی که در طول یک چرخه جمع‌آوری زباله ترکیبی جمع‌آوری می‌شوند، تعیین می‌کند. مقدار پیش‌فرض ۱۰ درصد از هیپ جاوا است.
درصدی از هیپ (۰ تا ۵۰) را تعیین می‌کند که به‌عنوان سقف کاذب برای کاهش احتمال خطای ارتقا (promotion failure) برای جمع‌آورنده G1 رزرو می‌شود. هنگام افزایش یا کاهش این درصد، مطمئن شوید که کل هیپ جاوا را به همان میزان تنظیم می‌کنید. به‌طور پیش‌فرض، این گزینه روی ۱۰% تنظیم شده است.

مثال زیر هیپ رزرو شده را روی ۲۰% تنظیم می‌کند:

-XX:G1ReservePercent=20

محاسبه تطبیقی میزان اشغال نسل قدیمی را برای شروع کارهای پس‌زمینه آماده‌سازی جهت جمع‌آوری نسل قدیمی کنترل می‌کند. در صورت فعال بودن، G1 در دفعات اول همان‌طور که با مقدار -XX:G1AdaptiveIHOPNumInitialSamples مشخص شده از -XX:InitiatingHeapOccupancyPercent استفاده می‌کند، و پس از آن مقدار بهینه جدیدی را برای اشغال اولیه به‌طور خودکار محاسبه می‌کند. در غیر این صورت، فرآیند جمع‌آوری نسل قدیمی همیشه در میزان اشغال نسل قدیمی تعیین‌شده توسط -XX:InitiatingHeapOccupancyPercent آغاز می‌شود.

به‌طور پیش‌فرض فعال است.

اندازه اولیه (به بایت) مخزن تخصیص حافظه را تعیین می‌کند. این مقدار باید ۰ یا مضربی از ۱۰۲۴ و بزرگ‌تر از ۱ مگابایت باشد. حرف k یا K را برای نشان دادن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود.

مثال‌های زیر نحوه تنظیم اندازه حافظه تخصیص‌یافته روی ۶ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:


-XX:InitialHeapSize=6291456
-XX:InitialHeapSize=6144k
-XX:InitialHeapSize=6m

اگر این گزینه را روی ۰ تنظیم کنید، اندازه اولیه برابر با مجموع اندازه‌های تخصیص‌یافته برای نسل قدیمی و نسل جوان تنظیم می‌شود. اندازه هیپ برای نسل جوان را می‌توان با استفاده از گزینه -XX:NewSize تعیین کرد.

میزان اولیه حافظه‌ای را که JVM قبل از اعمال روش‌های ابتکاری ارگونومی برای هیپ جاوا استفاده می‌کند، به‌صورت درصدی از حداکثر مقدار تعیین‌شده مطابق با گزینه -XX:MaxRAM تنظیم می‌کند. مقدار پیش‌فرض ۱.۵۶۲۵ درصد است.

مثال زیر نحوه تنظیم درصد مقدار اولیه حافظه مورد استفاده برای هیپ جاوا را نشان می‌دهد:

-XX:InitialRAMPercentage=5

نسبت اولیه فضای بازمانده (survivor space) مورد استفاده توسط جمع‌آورنده زباله توان عملیاتی (throughput garbage collector) را که با گزینه -XX:+UseParallelGC فعال می‌شود، تنظیم می‌کند. اندازه‌گیری تطبیقی به‌طور پیش‌فرض در جمع‌آورنده زباله throughput با استفاده از گزینه -XX:+UseParallelGC فعال است و فضای بازمانده با شروع از مقدار اولیه، متناسب با رفتار برنامه تغییر اندازه می‌یابد. اگر اندازه‌گیری تطبیقی غیرفعال باشد (با استفاده از گزینه -XX:-UseAdaptiveSizePolicy)، باید از گزینه -XX:SurvivorRatio برای تنظیم اندازه فضای بازمانده در تمام طول اجرای برنامه استفاده شود.

فرمول زیر می‌تواند برای محاسبه اندازه اولیه فضای بازمانده (S) بر اساس اندازه نسل جوان (Y) و نسبت اولیه فضای بازمانده (R) استفاده شود:

S=Y/(R+2)

عدد ۲ در معادله نشان‌دهنده دو فضای بازمانده است. هر چه مقدار مشخص‌شده برای نسبت اولیه فضای بازمانده بزرگ‌تر باشد، اندازه اولیه فضای بازمانده کوچک‌تر خواهد بود.

به‌طور پیش‌فرض، نسبت اولیه فضای بازمانده روی ۸ تنظیم شده است. اگر از مقدار پیش‌فرض برای اندازه فضای نسل جوان (۲ مگابایت) استفاده شود، اندازه اولیه فضای بازمانده ۰.۲ مگابایت خواهد بود.

مثال زیر نحوه تنظیم نسبت اولیه فضای بازمانده روی ۴ را نشان می‌دهد:

-XX:InitialSurvivorRatio=4

درصد اشغال نسل قدیمی (۰ تا ۱۰۰) را که در آن اولین چرخه‌های نشانه‌گذاری هم‌روند برای جمع‌آورنده زباله G1 آغاز می‌شود، تعیین می‌کند.

به‌طور پیش‌فرض، مقدار اولیه روی ۴۵% تنظیم شده است. مقدار ۰ به معنای چرخه‌های GC هم‌روند بدون توقف از ابتدا است تا زمانی که G1 این مقدار را به‌صورت تطبیقی تنظیم کند.

همچنین گزینه‌های -XX:G1UseAdaptiveIHOP و -XX:G1AdaptiveIHOPNumInitialSamples را ببینید.

مثال زیر نحوه تنظیم اشغال هیپ اولیه روی ۷۵% را نشان می‌دهد:

-XX:InitiatingHeapOccupancyPercent=75

هدفی را برای حداکثر زمان توقف GC (به میلی‌ثانیه) تعیین می‌کند. این یک هدف منعطف (soft goal) است و JVM تمام تلاش خود را برای رسیدن به آن انجام خواهد داد. مقدار مشخص‌شده با اندازه هیپ شما تطبیق پیدا نمی‌کند. به‌طور پیش‌فرض، برای G1 هدف حداکثر زمان توقف ۲۰۰ میلی‌ثانیه است. سایر جمع‌آورنده‌های نسلی به‌طور پیش‌فرض از هدف زمان توقف استفاده نمی‌کنند.

مثال زیر نحوه تنظیم حداکثر زمان توقف هدف را روی ۵۰۰ میلی‌ثانیه نشان می‌دهد:

-XX:MaxGCPauseMillis=500

حداکثر اندازه (به بایت) مخزن تخصیص حافظه را تعیین می‌کند. این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۲ مگابایت باشد. حرف k یا K را برای نشان دادن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود. برای استقرارهای سرور، گزینه‌های -XX:InitialHeapSize و -XX:MaxHeapSize اغلب روی مقداری یکسان تنظیم می‌شوند.

مثال‌های زیر نحوه تنظیم حداکثر اندازه مجاز حافظه تخصیص‌یافته روی ۸۰ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:


-XX:MaxHeapSize=83886080
-XX:MaxHeapSize=81920k
-XX:MaxHeapSize=80m

گزینه -XX:MaxHeapSize معادل -Xmx است.

حداکثر درصد مجاز فضای خالی هیپ (۰ تا ۱۰۰) را پس از یک رویداد GC تعیین می‌کند. اگر فضای خالی هیپ بیش از این مقدار گسترش یابد، هیپ کوچک می‌شود. به‌طور پیش‌فرض، این مقدار روی ۷۰% تنظیم شده است.

اندازه هیپ جاوا را با کاهش مقادیر پارامترهای MaxHeapFreeRatio (مقدار پیش‌فرض ۷۰%) و MinHeapFreeRatio (مقدار پیش‌فرض ۴۰%) از طریق گزینه‌های خط فرمان -XX:MaxHeapFreeRatio و -XX:MinHeapFreeRatio به حداقل برسانید. کاهش MaxHeapFreeRatio تا ۱۰% و MinHeapFreeRatio تا ۵%، اندازه هیپ را با موفقیت و بدون افت کارایی زیاد کاهش داده است؛ با این حال، نتایج ممکن است بسته به برنامه شما بسیار متفاوت باشد. مقادیر مختلف را برای این پارامترها امتحان کنید تا جایی که در کمترین حالت ممکن باشند و در عین حال کارایی قابل‌قبولی را حفظ کنند.

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

کاربرانی که تلاش می‌کنند هیپ را کوچک نگه دارند باید گزینه -XX:-ShrinkHeapInSteps را نیز اضافه کنند. برای توضیحات مربوط به استفاده از این گزینه جهت کوچک نگه داشتن هیپ جاوا با کاهش ردپای حافظه پویا برای برنامه‌های تعبیه‌شده (embedded)، بخش مثال‌های تنظیم کارایی (Performance Tuning Examples) را ببینید.

حداکثر مقدار حافظه بومی (native memory) را که می‌تواند برای فراداده کلاس (class metadata) تخصیص یابد، تعیین می‌کند. به‌طور پیش‌فرض، اندازه محدود نیست. مقدار فراداده برای یک برنامه به خود برنامه، سایر برنامه‌های در حال اجرا و مقدار حافظه موجود در سیستم بستگی دارد.

مثال زیر نحوه تنظیم حداکثر اندازه فراداده کلاس را روی ۲۵۶ مگابایت نشان می‌دهد:

-XX:MaxMetaspaceSize=256m

حداکثر اندازه (به بایت) هیپ را برای نسل جوان (nursery) تعیین می‌کند. مقدار پیش‌فرض به‌صورت ارگونومیک تنظیم می‌شود.
حداکثر مقدار حافظه‌ای را که JVM می‌تواند برای هیپ جاوا قبل از اعمال روش‌های ارگونومی استفاده کند، تعیین می‌کند. مقدار پیش‌فرض، حداکثر مقدار حافظه در دسترس فرایند JVM یا ۱۲۸ گیگابایت است (هرکدام که کمتر باشد).

حداکثر مقدار حافظه در دسترس فرایند JVM برابر است با کمینه حافظه فیزیکی دستگاه و هرگونه محدودیت تعیین‌شده توسط محیط (مانند کانتینر).

اگر نتیجه ترکیب این گزینه و سایر گزینه‌های مؤثر بر حداکثر مقدار حافظه، بزرگ‌تر از محدوده حافظه آدرس‌پذیر توسط oops فشرده باشد، مشخص کردن این گزینه استفاده خودکار از compressed oops را غیرفعال می‌کند. برای اطلاعات بیشتر درباره compressed oops، به -XX:UseCompressedOops مراجعه کنید.

مثال زیر نحوه تنظیم حداکثر مقدار حافظه در دسترس برای تعیین اندازه هیپ جاوا روی ۲ گیگابایت را نشان می‌دهد:

-XX:MaxRAM=2G

حداکثر مقدار حافظه‌ای را که JVM می‌تواند برای هیپ جاوا قبل از اعمال ارگونومیک به عنوان درصدی از حداکثر مقدار تعیین‌شده (همان‌طور که در گزینه -XX:MaxRAM شرح داده شده) استفاده کند، تنظیم می‌کند. مقدار پیش‌فرض 25 درصد است.

مشخص کردن این گزینه، استفاده خودکار از اشاره‌گرهای فشرده (compressed oops) را در صورتی که نتیجه ترکیب این گزینه و سایر گزینه‌های مؤثر بر حداکثر حافظه بزرگ‌تر از محدوده حافظه قابل‌آدرس‌دهی توسط compressed oops باشد، غیرفعال می‌کند. برای اطلاعات بیشتر درباره اشاره‌گرهای فشرده، گزینه -XX:UseCompressedOops را ببینید.

مثال زیر نحوه تنظیم درصد حداکثر مقدار حافظه مورد استفاده برای هیپ جاوا را نشان می‌دهد:

-XX:MaxRAMPercentage=75

حداکثر مقدار حافظه‌ای را که JVM می‌تواند برای هیپ جاوا قبل از اعمال ارگونومیک به عنوان درصدی از حداکثر مقدار تعیین‌شده (همان‌طور که در گزینه -XX:MaxRAM شرح داده شده) برای هیپ‌های کوچک استفاده کند، تنظیم می‌کند. یک هیپ کوچک، هیپی با اندازه تقریبی ۱۲۵ مگابایت است. مقدار پیش‌فرض 50 درصد است.

مثال زیر نحوه تنظیم درصد حداکثر مقدار حافظه مورد استفاده برای هیپ جاوا را برای هیپ‌های کوچک نشان می‌دهد:

-XX:MinRAMPercentage=75

حداکثر آستانه ارتقای نسل (tenuring threshold) را برای استفاده در تنظیم اندازه تطبیقی GC مشخص می‌کند. بزرگ‌ترین مقدار مجاز 15 است. مقدار پیش‌فرض برای زباله‌روب موازی (throughput) برابر با 15 است.

مثال زیر نحوه تنظیم حداکثر آستانه ارتقای نسل به 10 را نشان می‌دهد:

-XX:MaxTenuringThreshold=10

اندازه فضای متادیتای کلاس تخصیص‌یافته را تنظیم می‌کند که فراتر رفتن از آن برای اولین بار، اجرای فرایند زباله‌روبی را تحریک می‌کند. این آستانه برای زباله‌روبی، بسته به میزان متادیتای استفاده‌شده افزایش یا کاهش می‌یابد. اندازه پیش‌فرض به پلتفرم بستگی دارد.
حداقل درصد مجاز فضای خالی هیپ (۰ تا ۱۰۰) پس از یک رویداد GC را تنظیم می‌کند. اگر فضای خالی هیپ به کمتر از این مقدار برسد، هیپ گسترش می‌یابد. به صورت پیش‌فرض، این مقدار روی 40% تنظیم شده است.

با کاهش مقادیر پارامترهای MaxHeapFreeRatio (مقدار پیش‌فرض 70%) و MinHeapFreeRatio (مقدار پیش‌فرض 40%) با استفاده از گزینه‌های خط فرمان -XX:MaxHeapFreeRatio و -XX:MinHeapFreeRatio، اندازه هیپ جاوا را به حداقل برسانید. کاهش MaxHeapFreeRatio تا 10% و MinHeapFreeRatio تا 5% با موفقیت اندازه هیپ را بدون افت کارایی چشمگیر کاهش داده است؛ با این حال، نتایج بسته به برنامه شما ممکن است بسیار متفاوت باشد. مقادیر مختلف را برای این پارامترها امتحان کنید تا جایی که تا حد امکان کم باشند و در عین حال کارایی قابل قبولی را حفظ کنند.

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

کاربرانی که تلاش می‌کنند هیپ را کوچک نگه دارند باید گزینه -XX:-ShrinkHeapInSteps را نیز اضافه کنند. برای توضیحات مربوط به استفاده از این گزینه برای کوچک نگه داشتن هیپ جاوا از طریق کاهش ردپای حافظه پویا برای برنامه‌های تعبیه‌شده (embedded)، به بخش مثال‌های تنظیم کارایی (Performance Tuning Examples) مراجعه کنید.

حداقل اندازه (به بایت) استخر تخصیص حافظه را تنظیم می‌کند. این مقدار باید 0 یا مضربی از 1024 و بزرگ‌تر از 1 مگابایت باشد. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود.

مثال‌های زیر نحوه تنظیم حداقل اندازه حافظه تخصیص‌یافته به 6 مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:


-XX:MinHeapSize=6291456
-XX:MinHeapSize=6144k
-XX:MinHeapSize=6m

اگر این گزینه را روی 0 تنظیم کنید، حداقل اندازه برابر با مقدار اندازه اولیه تنظیم می‌شود.

نسبت بین اندازه‌های نسل جوان (young generation) و نسل قدیم (old generation) را تنظیم می‌کند. به صورت پیش‌فرض، این گزینه روی 2 تنظیم شده است. مثال زیر نحوه تنظیم نسبت نسل جوان به قدیم را روی 1 نشان می‌دهد:

-XX:NewRatio=1

اندازه اولیه (به بایت) هیپ برای نسل جوان (nursery) را تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید.

ناحیه نسل جوان هیپ برای اشیاء جدید استفاده می‌شود. فرایند GC در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد. اگر اندازه نسل جوان بیش از حد کم باشد، تعداد زیادی GC جزئی (minor GC) انجام خواهد شد. اگر اندازه بیش از حد زیاد باشد، فقط GCهای کامل (full GC) اجرا می‌شوند که ممکن است زمان زیادی برای تکمیل نیاز داشته باشند. توصیه می‌شود اندازه نسل جوان را بیش از 25% و کمتر از 50% از کل اندازه هیپ نگه دارید.

مثال‌های زیر نحوه تنظیم اندازه اولیه نسل جوان به 256 مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:


-XX:NewSize=256m
-XX:NewSize=262144k
-XX:NewSize=268435456

گزینه -XX:NewSize معادل -Xmn است.

تعداد نخ‌های پردازشی کارگر توقف کل دنیا (stop-the-world یا STW) را تنظیم می‌کند. مقدار پیش‌فرض به تعداد CPUهای در دسترس JVM و زباله‌روب انتخاب‌شده بستگی دارد.

برای مثال، جهت تنظیم تعداد نخ‌ها برای زباله‌روب G1 به ۲، گزینه زیر را مشخص کنید:

-XX:ParallelGCThreads=2

پردازش موازی ارجاعات را فعال می‌کند. به صورت پیش‌فرض، این گزینه غیرفعال است.
چاپ اطلاعات مربوط به اندازه‌بندی تطبیقی نسل‌ها را فعال می‌کند. به صورت پیش‌فرض، این گزینه غیرفعال است.
مدت زمانی (به میلی‌ثانیه) را که یک شیء با دسترسی نرم (softly reachable) پس از آخرین باری که به آن ارجاع داده شده روی هیپ فعال باقی می‌ماند، تنظیم می‌کند. مقدار پیش‌فرض یک ثانیه طول عمر به ازای هر مگابایت فضای خالی در هیپ است. گزینه -XX:SoftRefLRUPolicyMSPerMB مقادیر صحیحی را می‌پذیرد که نشان‌دهنده میلی‌ثانیه به ازای یک مگابایت از اندازه فعلی هیپ (برای ماشین مجازی Java HotSpot Client) یا حداکثر اندازه ممکن هیپ (برای ماشین مجازی Java HotSpot Server) است. این تفاوت به این معناست که Client VM تمایل دارد به جای افزایش اندازه هیپ، ارجاعات نرم را پاکسازی کند، در حالی که Server VM تمایل دارد به جای پاکسازی ارجاعات نرم، اندازه هیپ را افزایش دهد. در حالت دوم، مقدار گزینه -Xmx تأثیر بسزایی بر سرعت زباله‌روبی ارجاعات نرم دارد.

مثال زیر نحوه تنظیم این مقدار به 2.5 ثانیه را نشان می‌دهد:

-XX:SoftRefLRUPolicyMSPerMB=2500

هیپ جاوا را به صورت مرحله‌ای و تدریجی به اندازه هدف مشخص‌شده توسط گزینه -XX:MaxHeapFreeRatio کاهش می‌دهد. این گزینه به صورت پیش‌فرض فعال است. در صورت غیرفعال بودن، هیپ جاوا را به جای نیاز به چندین چرخه زباله‌روبی، بلافاصله به اندازه هدف کاهش می‌دهد. اگر می‌خواهید اندازه هیپ جاوا را به حداقل برسانید، این گزینه را غیرفعال کنید. هنگامی که این گزینه غیرفعال است، احتمالاً با افت کارایی مواجه خواهید شد.

برای شرح استفاده از گزینه MaxHeapFreeRatio جهت کوچک نگه داشتن هیپ جاوا از طریق کاهش ردپای حافظه پویا برای برنامه‌های تعبیه‌شده، به بخش مثال‌های تنظیم کارایی (Performance Tuning Examples) مراجعه کنید.

اشیاء String را که به سن مشخص‌شده می‌رسند و کاندیدای یکتا‌سازی (deduplication) در نظر گرفته می‌شوند، شناسایی می‌کند. سن یک شیء معیاری از تعداد دفعاتی است که از زباله‌روبی جان سالم به در برده است. گاهی اوقات به این مفهوم ارتقای نسل (tenuring) نیز گفته می‌شود.

نکته: اشیاء String که قبل از رسیدن به این سن به ناحیه نسل قدیم هیپ ارتقا می‌یابند، همیشه کاندیدای یکتا‌سازی در نظر گرفته می‌شوند. مقدار پیش‌فرض برای این گزینه 3 است. گزینه -XX:+UseStringDeduplication را ببینید.

نسبت بین اندازه فضای eden و اندازه فضای survivor را تنظیم می‌کند. به صورت پیش‌فرض، این گزینه روی 8 تنظیم شده است. مثال زیر نحوه تنظیم نسبت فضای eden/survivor به 4 را نشان می‌دهد:

-XX:SurvivorRatio=4

درصد مطلوب فضای survivor مورد استفاده پس از زباله‌روبی نسل جوان را (۰ تا ۱۰۰) تنظیم می‌کند. به صورت پیش‌فرض، این گزینه روی 50% تنظیم شده است.

مثال زیر نحوه تنظیم نسبت هدف فضای survivor به 30% را نشان می‌دهد:

-XX:TargetSurvivorRatio=30

اندازه اولیه (به بایت) بافر تخصیص محلی نخ (TLAB) را تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. اگر این گزینه روی 0 تنظیم شود، JVM اندازه اولیه را به طور خودکار انتخاب می‌کند.

مثال زیر نحوه تنظیم اندازه اولیه TLAB به 512 کیلوبایت را نشان می‌دهد:

-XX:TLABSize=512k

استفاده از اندازه‌بندی تطبیقی نسل‌ها را فعال می‌کند. این گزینه به صورت پیش‌فرض فعال است. برای غیرفعال کردن اندازه‌بندی تطبیقی نسل‌ها، گزینه -XX:-UseAdaptiveSizePolicy را مشخص کرده و اندازه استخر تخصیص حافظه را به صورت صریح تنظیم کنید. گزینه -XX:SurvivorRatio را ببینید.
استفاده از زباله‌روب اولویت با زباله (G1 یا Garbage-First) را فعال می‌کند. این یک زباله‌روب مخصوص سرور است که برای ماشین‌های چندپردازنده‌ای با مقدار زیاد رم طراحی شده است. این گزینه با احتمال بالا اهداف زمان توقف GC را برآورده کرده و در عین حال توان پردازشی (throughput) خوبی را حفظ می‌کند. زباله‌روب G1 برای برنامه‌هایی پیشنهاد می‌شود که به هیپ‌های بزرگ (اندازه‌های حدود ۶ گیگابایت یا بزرگ‌تر) با محدودیت‌های تاخیر GC (زمان توقف پایدار و قابل پیش‌بینی کمتر از ۰.۵ ثانیه) نیاز دارند. به صورت پیش‌فرض، این گزینه فعال است و G1 به عنوان زباله‌روب پیش‌فرض استفاده می‌شود.
استفاده از سیاستی را فعال می‌کند که نسبت زمان صرف‌شده توسط JVM برای GC را قبل از پرتاب استثنای OutOfMemoryError محدود می‌سازد. این گزینه به طور پیش‌فرض فعال است و اگر بیش از 98% از کل زمان صرف زباله‌روبی شود و کمتر از 2% از هیپ بازیابی گردد، GC موازی خطای OutOfMemoryError را پرتاب خواهد کرد. هنگامی که هیپ کوچک است، از این ویژگی می‌توان برای جلوگیری از اجرای طولانی‌مدت برنامه‌ها با پیشرفت کم یا بدون پیشرفت استفاده کرد. برای غیرفعال کردن این گزینه، گزینه -XX:-UseGCOverheadLimit را مشخص کنید.
بهینه‌سازی کارایی برنامه را روی ماشینی با معماری حافظه غیریکنواخت (NUMA) از طریق افزایش استفاده برنامه از حافظه با تاخیر کمتر فعال می‌کند. به صورت پیش‌فرض، این گزینه غیرفعال است و هیچ بهینه‌سازی برای NUMA انجام نمی‌شود. این گزینه تنها زمانی در دسترس است که از زباله‌روب موازی استفاده شود (-XX:+UseParallelGC).
استفاده از زباله‌روب موازی (Parallel Scavenge که به عنوان throughput collector نیز شناخته می‌شود) را برای بهبود کارایی برنامه از طریق بهره‌گیری از چندین پردازنده فعال می‌کند.

به صورت پیش‌فرض، این گزینه غیرفعال است و از زباله‌روب پیش‌فرض استفاده می‌شود.

استفاده از زباله‌روب سریالی (Serial Garbage Collector) را فعال می‌کند. این گزینه عموماً بهترین انتخاب برای برنامه‌های کوچک و ساده است که به قابلیت‌های خاصی از زباله‌روبی نیاز ندارند. به صورت پیش‌فرض، این گزینه غیرفعال است و از زباله‌روب پیش‌فرض استفاده می‌شود.
یکتا‌سازی رشته‌ها (string deduplication) را فعال می‌کند. به صورت پیش‌فرض، این گزینه غیرفعال است. برای استفاده از این گزینه، باید زباله‌روب اولویت با زباله (G1) را فعال کنید.

یکتا‌سازی رشته‌ها با بهره‌گیری از این واقعیت که بسیاری از اشیاء String یکسان هستند، ردپای حافظه اشیاء String را روی هیپ جاوا کاهش می‌دهد. به جای اینکه هر شیء String به آرایه نویسه‌های اختصاصی خود اشاره کند، اشیاء String یکسان می‌توانند به یک آرایه نویسه مشترک اشاره کرده و آن را به اشتراک بگذارند.

استفاده از بلوک‌های تخصیص محلی نخ (TLAB) را در فضای نسل جوان فعال می‌کند. این گزینه به صورت پیش‌فرض فعال است. برای غیرفعال کردن استفاده از TLAB، گزینه -XX:-UseTLAB را مشخص کنید.
استفاده از زباله‌روب Z (موسوم به ZGC) را فعال می‌کند. این یک زباله‌روب با تاخیر کم است که حداکثر زمان توقف در حد چند میلی‌ثانیه را با مقداری هزینه در توان پردازشی فراهم می‌کند. زمان‌های توقف مستقل از اندازه هیپ مورد استفاده هستند. از اندازه‌های هیپ بین ۸ مگابایت تا ۱۶ ترابایت پشتیبانی می‌کند.
میزان تحمل جهش تخصیص حافظه (allocation spike tolerance) را برای ZGC تنظیم می‌کند. به صورت پیش‌فرض، این گزینه روی 2.0 تنظیم شده است. این ضریب سطح جهش‌های تخصیص قابل‌انتظار را توصیف می‌کند. به عنوان مثال، استفاده از ضریب 3.0 به این معنی است که نرخ تخصیص فعلی می‌تواند در هر لحظه سه برابر شود.
حداکثر فاصله زمانی (به ثانیه) بین دو چرخه GC را هنگام استفاده از ZGC مشخص می‌کند. به صورت پیش‌فرض، این گزینه روی 0 (غیرفعال) تنظیم شده است.
حداکثر قطعه‌قطعه شدن مجاز هیپ (به درصد) را برای ZGC مشخص می‌کند. به صورت پیش‌فرض، این گزینه روی 25 تنظیم شده است. استفاده از مقدار کمتر باعث می‌شود هیپ به صورت تهاجمی‌تری فشرده‌سازی شود تا حافظه بیشتری به بهای مصرف زمان بیشتر CPU آزاد گردد.
چرخه‌های پیش‌دستانه (proactive) زباله‌روبی را هنگام استفاده از ZGC فعال می‌کند. این گزینه به صورت پیش‌فرض فعال است. اگر انتظار برود که اجرای زباله‌روبی تأثیر ناچیزی بر برنامه در حال اجرا داشته باشد، ZGC چرخه GC پیش‌دستانه را آغاز می‌کند. این قابلیت در صورتی مفید است که برنامه بیشتر در حالت غیرفعال باشد یا اشیاء بسیار کمی تخصیص دهد، اما همچنان بخواهید اندازه هیپ را پایین نگه داشته و به پردازش ارجاعات اجازه اجرا دهید حتی زمانی که فضای خالی زیادی روی هیپ وجود دارد.
آزادسازی حافظه هیپ استفاده‌نشده (uncommit) را در هنگام استفاده از ZGC فعال می‌کند. این گزینه به صورت پیش‌فرض فعال است. آزادسازی حافظه استفاده‌نشده هیپ، ردپای حافظه JVM را کاهش داده و آن حافظه را برای استفاده سایر فرآیندها در دسترس قرار می‌دهد.
مدت زمانی (به ثانیه) را تعیین می‌کند که حافظه هیپ قبل از آزادسازی (uncommit) باید استفاده‌نشده باقی مانده باشد. به صورت پیش‌فرض، این گزینه روی 300 (۵ دقیقه) تنظیم شده است. تخصیص مجدد و آزادسازی حافظه عملیات نسبتاً هزینه‌بری هستند. استفاده از مقدار کمتر باعث می‌شود حافظه هیپ زودتر آزاد شود، با این ریسک که ممکن است خیلی زود نیاز به تخصیص مجدد آن باشد.
استفاده از جمع‌آوری‌کننده زباله Shenandoah را فعال می‌کند. این یک جمع‌آوری‌کننده زباله همگام با زمان توقف کوتاه است. زمان‌های توقف آن متناسب با اندازه هیپ نیست. جمع‌آوری‌کننده زباله Shenandoah می‌تواند با اشاره‌گرهای فشرده کار کند. گزینه -XX:UseCompressedOops را ببینید.
حالت جمع‌آوری زباله را برای Shenandoah GC تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی satb تنظیم شده است. این گزینه در میان موارد دیگر، مشخص می‌کند کدام موانع (barriers) در حال استفاده هستند. مقادیر ممکن برای حالت شامل موارد زیر است:
جمع‌آوری زباله همگام براساس عکس‌برداری در آغاز (سه مرحله علامت‌گذاری-تخلیه-به‌روزرسانی). این یک GC تک‌نسلی (single generation) است.
این حالت نیز یک GC همگام و مبتنی بر عکس‌برداری در آغاز است، اما به‌صورت چندنسلی (generational) عمل می‌کند. لطفاً برای آگاهی از مزایا و خطرات آن، به JEP 404 [https://openjdk.org/jeps/404] و JEP 521 [https://openjdk.org/jeps/521] مراجعه کنید.
روش‌های اکتشافی (heuristics) را برای Shenandoah GC تعیین می‌کند. به‌طور پیش‌فرض، این گزینه روی adaptive تنظیم شده است. این گزینه با انتخاب زمان شروع GC، میزان پردازش در هر چرخه و فعال‌سازی خودکار سایر ویژگی‌ها، حالت GC انتخاب‌شده را بهینه‌سازی و تنظیم دقیق می‌کند. روش‌های اکتشافی ممکن شامل موارد زیر است:
برای حفظ مقدار مشخصی از فضای خالی هیپ در همه زمان‌ها، حتی در طول چرخه GC.
شروع GC هنگامی که فضای خالی هیپ به زیر آستانه مشخص‌شده کاهش یابد.
اجرای مکررتر GC و با اهداف عمیق‌تر جهت آزادسازی حافظه بیشتر.

این گزینه‌های java منسوخ شده‌اند و ممکن است در نسخه‌های آینده JDK حذف شوند. این گزینه‌ها هنوز پذیرفته شده و اعمال می‌شوند، اما در صورت استفاده از آن‌ها هشدار صادر می‌شود.

فایلی را تنظیم می‌کند که اطلاعات رویدادهای مفصل GC باید برای ثبت لاگ به آن هدایت شود. اگر هر دو گزینه با یک دستور java ارائه شوند، گزینه -Xloggc بر -verbose:gc تقدم دارد. گزینه -Xloggc:filename با -Xlog:gc:filename جایگزین شده است. به بخش «فعال‌سازی لاگ با چارچوب لاگ یکپارچه JVM» مراجعه کنید.
مثال: -Xlog:gc:garbage-collection.log
استفاده از Java Flight Recorder (JFR) را در زمان اجرای برنامه فعال می‌کند. از زمان JDK 8u40 این گزینه برای استفاده از JFR الزامی نبوده است.

این گزینه‌های java هنوز پذیرفته می‌شوند اما نادیده گرفته می‌شوند، و در صورت استفاده از آن‌ها هشدار صادر می‌شود.

-illegal-access=parameter
ویژگی «کپسوله‌سازی قوی با انعطاف‌پذیری» را کنترل می‌کرد، همان‌طور که در JEP 261 [https://openjdk.org/jeps/261#Relaxed-strong-encapsulation] تعریف شده بود. این گزینه در JDK 16 توسط JEP 396 [https://openjdk.org/jeps/396] منسوخ شد و در JDK 17 توسط JEP 403 [https://openjdk.org/jeps/403] متروکه گردید.

این گزینه‌های java در JDK 25 حذف شده‌اند و استفاده از آن‌ها منجر به خطای زیر می‌شود:

Unrecognized VM option option-name

نسبت سقط RTM را به عنوان درصدی (%) از تمام تراکنش‌های RTM اجرا شده مشخص می‌کند. اگر تعداد تراکنش‌های سقط‌شده از این نسبت بیشتر شود، کد کامپایل‌شده بهینه‌زدایی (deoptimize) می‌شود. این نسبت زمانی استفاده می‌شود که گزینه -XX:+UseRTMDeopt فعال باشد. مقدار پیش‌فرض این گزینه 50 است. این بدان معنی است که اگر ۵۰٪ از تمام تراکنش‌ها سقط شوند، کد کامپایل‌شده بهینه‌زدایی می‌شود.
تعداد دفعاتی را مشخص می‌کند که در صورت سقط یا شلوغ بودن قفل، کد قفل‌گذاری RTM قبل از بازگشت به سازوکار قفل‌گذاری عادی دوباره تلاش می‌شود. مقدار پیش‌فرض این گزینه 5 است. گزینه -XX:UseRTMLocking باید فعال باشد.
قفل‌گذاری RTM را بسته به نسبت سقط به‌طور خودکار تنظیم می‌کند. این نسبت توسط گزینه -XX:RTMAbortRatio مشخص می‌شود. اگر تعداد تراکنش‌های سقط‌شده از نسبت سقط فراتر رود، متد حاوی قفل بهینه‌زدایی شده و تمام قفل‌ها به عنوان قفل‌های عادی دوباره کامپایل می‌شوند. این گزینه به‌طور پیش‌فرض غیرفعال است. گزینه -XX:+UseRTMLocking باید فعال باشد.
کد قفل‌گذاری حافظه تراکنشی محدود (RTM) را برای تمام قفل‌های متورم (inflated locks) با سازوکار قفل‌گذاری عادی به عنوان گرداننده بازگشتی (fallback) تولید می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. گزینه‌های مربوط به RTM تنها در پردازنده‌های x86 که از افزونه‌های همگام‌سازی تراکنشی (TSX) پشتیبانی می‌کنند در دسترس هستند.
ویژگی RTM بخشی از اینتل TSX است که یک افزونه مجموعه دستورات x86 بوده و ایجاد برنامه‌های چندنخی را تسهیل می‌کند. دستورالعمل‌های جدید XBEGIN، XABORT، XEND و XTEST توسط RTM معرفی می‌شوند. دستورهای XBEGIN و XEND مجموعه‌ای از دستورات را برای اجرا به عنوان یک تراکنش محصور می‌کنند. اگر هنگام اجرای تراکنش تعارضی یافت نشود، تغییرات حافظه و رجیستر در دستور XEND با هم ثبت (commit) می‌شوند. دستور XABORT می‌تواند برای سقط صریح یک تراکنش استفاده شود و دستور XTEST بررسی می‌کند که آیا مجموعه‌ای از دستورات در یک تراکنش در حال اجرا هستند یا خیر. یک قفل روی تراکنش زمانی متورم می‌شود که نخ دیگری سعی در دسترسی به همان تراکنش داشته باشد، در نتیجه نخی که در ابتدا درخواست دسترسی به تراکنش را نکرده بود مسدود می‌شود. دستور RTM مستلزم آن است که در صورت سقط یا شکست یک تراکنش، یک مجموعه عملیات بازگشتی (fallback) تعیین شود. قفل RTM قفلی است که به سیستم TSX تفویض شده است. ویژگی RTM کارایی را برای قفل‌های با رقابت بالا و تعارض کم در یک ناحیه بحرانی (که کدی است که بیش از یک نخ نباید هم‌زمان به آن دسترسی داشته باشند) بهبود می‌بخشد. همچنین RTM کارایی قفل‌گذاری درشت‌دانه (coarse-grain locking) را که معمولاً در برنامه‌های چندنخی عملکرد خوبی ندارد، بهبود می‌بخشد. (قفل‌گذاری درشت‌دانه استراتژی نگه‌داشتن قفل‌ها برای دوره‌های طولانی به منظور به حداقل رساندن بار اضافی اخذ و آزادسازی قفل‌ها است، در حالی که قفل‌گذاری ریزدانه استراتژی تلاش برای دستیابی به حداکثر موازی‌سازی با قفل کردن فقط در زمان نیاز و باز کردن قفل در سریع‌ترین زمان ممکن است.) همچنین، برای قفل‌های با رقابت کم که توسط نخ‌های مختلف استفاده می‌شوند، RTM می‌تواند اشتراک خط حافظه پنهان کاذب (false cache line sharing) را که با نام پینگ‌پنگ خط حافظه پنهان نیز شناخته می‌شود، کاهش دهد. این اتفاق زمانی رخ می‌دهد که چندین نخ از پردازنده‌های مختلف به منابع مختلف دسترسی دارند، اما منابع یک خط حافظه پنهان مشترک دارند. در نتیجه، پردازنده‌ها مکرراً خطوط حافظه پنهان پردازنده‌های دیگر را نامعتبر می‌کنند، که آن‌ها را مجبور می‌کند به جای حافظه پنهان، از حافظه اصلی بخوانند.

برای مشاهده فهرست‌ها و شرح گزینه‌های حذف‌شده در نسخه‌های قبلی، به بخش گزینه‌های حذف‌شده جاوا (Removed Java Options) در اسناد زیر مراجعه کنید:

شما می‌توانید با استفاده از فایل‌های آرگومان @ برای مشخص کردن یک یا چند فایل متنی حاوی آرگومان‌ها (مانند گزینه‌ها و نام کلاس‌ها) که به دستور java ارسال می‌شوند، دستور java را کوتاه‌تر یا ساده‌تر کنید. این قابلیت به شما امکان می‌دهد در هر سیستم‌عاملی دستورات java با هر طولی ایجاد کنید.

در خط فرمان، از پیشوند علامت اتساین (@) برای مشخص کردن یک فایل آرگومان حاوی گزینه‌ها و نام کلاس‌های java استفاده کنید. هنگامی که دستور java با فایلی مواجه می‌شود که با علامت اتساین (@) شروع می‌شود، محتوای آن فایل را دقیقاً همان‌گونه که در خط فرمان مشخص می‌شد، در یک لیست آرگومان باز (expand) می‌کند.

اجراکننده java محتویات فایل آرگومان را تا زمانی که با گزینه --disable-@files مواجه شود باز می‌کند. شما می‌توانید از گزینه --disable-@files در هر کجای خط فرمان، از جمله در یک فایل آرگومان، برای متوقف کردن باز کردن فایل‌های آرگومان @ استفاده کنید.

موارد زیر نحو و ساختار دستوری فایل‌های آرگومان java را شرح می‌دهند:

•
فایل آرگومان باید فقط شامل کاراکترهای ASCII یا کاراکترهایی در کدگذاری پیش‌فرض سیستم باشد که با ASCII سازگار هستند، مانند UTF-8.
•
حجم فایل آرگومان نباید از MAXINT (۲٬۱۴۷٬۴۸۳٬۶۴۷) بایت تجاوز کند.
•
اجراکننده کاراکترهای عمومی و الگوها (wildcards) را که درون یک فایل آرگومان وجود دارند باز نمی‌کند.
•
از کاراکترهای فاصله (white space) یا خط جدید برای جدا کردن آرگومان‌های موجود در فایل استفاده کنید.
•
فاصله خالی شامل کاراکتر فاصله، \t، \n، \r و \f است.

برای مثال، امکان دارد مسیری با فاصله داشته باشید، مانند c:\Program Files که می‌توان آن را به صورت "c:\\Program Files" یا برای جلوگیری از اسکیپ کردن، به صورت c:\Program" "Files مشخص کرد.

•
هر گزینه‌ای که حاوی فاصله باشد، مانند بخشی از یک مسیر، باید به طور کامل درون کاراکترهای نقل‌قول ('"') قرار گیرد.
•
یک رشته درون علامت‌های نقل‌قول می‌تواند حاوی کاراکترهای \n، \r، \t و \f باشد. این کاراکترها به کدهای ASCII متناظر خود تبدیل می‌شوند.
•
اگر نام یک فایل حاوی فاصله‌های درونی است، کل نام فایل را در جفت نقل‌قول دوتایی قرار دهید.
•
نام‌های فایل در یک فایل آرگومان نسبت به دایرکتوری جاری سنجیده می‌شوند، نه نسبت به مکان قرارگیری خود فایل آرگومان.
•
از علامت هش یا نامبر ساین # در فایل آرگومان برای مشخص کردن توضیحات (کامنت‌ها) استفاده کنید. تمام کاراکترهای پس از # تا انتهای خط نادیده گرفته می‌شوند.
•
پیشوندهای اتساین @ اضافی برای گزینه‌های دارای پیشوند @ به عنوان اسکیپ عمل می‌کنند (اولین @ حذف شده و بقیه آرگومان‌ها به صورت لغوی و بدون تغییر به اجراکننده تحویل داده می‌شوند).
•
خطوط را می‌توان با استفاده از کاراکتر ادامه (\) در انتهای خط ادامه داد. دو خط با حذف فاصله‌های خالی ابتدایی به یکدیگر متصل می‌شوند. برای جلوگیری از حذف فاصله‌های خالی ابتدایی، می‌توان یک کاراکتر ادامه (\) در ستون اول قرار داد.
•
از آنجا که بک‌اسلش (\) یک کاراکتر اسکیپ است، یک کاراکتر بک‌اسلش باید با یک کاراکتر بک‌اسلش دیگر اسکیپ شود.
•
نقل‌قول ناقص یا باز مجاز است و با انتهای فایل (end-of-file) بسته می‌شود.
•
نقل‌قول باز در انتهای خط متوقف می‌شود مگر اینکه \ آخرین کاراکتر باشد، که در این صورت با حذف تمام کاراکترهای فاصله ابتدایی به خط بعدی متصل می‌شود.
•
کاراکترهای الگو (*) در این لیست‌ها مجاز نیستند (مانند مشخص کردن *.java).
•
استفاده بازگشتی از علامت اتساین (@) برای تفسیر فایل‌ها پشتیبانی نمی‌شود.

در فایل آرگومان،


-cp "lib/
cool/
app/
jars

این به صورت زیر تفسیر می‌شود:

-cp lib/cool/app/jars

برای تولید خروجی زیر:

-cp c:\Program Files (x86)\Java\jre\lib\ext;c:\Program Files\Java\jre9\lib\ext

کاراکتر بک‌اسلش باید در فایل آرگومان به صورت زیر مشخص شود:

-cp "c:\\Program Files (x86)\\Java\\jre\\lib\\ext;c:\\Program Files\\Java\\jre9\\lib\\ext"

در فایل آرگومان،


-cp "/lib/cool app/jars:\
    /lib/another app/jars"

این به صورت زیر تفسیر می‌شود:

-cp /lib/cool app/jars:/lib/another app/jars

در فایل آرگومان،


-cp "/lib/cool\
\app/jars???

این به صورت زیر تفسیر می‌شود:

-cp /lib/cool app/jars

شما می‌توانید از یک فایل آرگومان تکی، مانند myargumentfile در مثال زیر، برای نگهداری تمام آرگومان‌های مورد نیاز java استفاده کنید:

java @myargumentfile

شما می‌توانید مسیرهای نسبی را در فایل‌های آرگومان بگنجانید؛ با این حال، این مسیرها نسبت به دایرکتوری کاری جاری سنجیده می‌شوند و نه نسبت به مسیرهای خود فایل‌های آرگومان. در مثال زیر، path1/options و path2/options نمایانگر فایل‌های آرگومان با مسیرهای مختلف هستند. هر مسیر نسبی که در آن‌ها باشد نسبت به دایرکتوری کاری جاری سنجیده می‌شود و نه فایل‌های آرگومان:

java @path1/options @path2/classes

گاهی اوقات داشتن بینش نسبت به وضعیت جاری هیپ کد (code heap) در JVM برای پاسخ به سوالاتی مانند موارد زیر مفید خواهد بود:

•
چرا JIT خاموش شد و سپس مکرراً روشن و خاموش شد؟
•
تمام فضای هیپ کد کجا مصرف شده است؟
•
چرا متد رُفتگر (method sweeper) به طور موثر کار نمی‌کند؟

برای ارائه این بینش، قابلیت تحلیل وضعیت هیپ کد پیاده‌سازی شده است که امکان تحلیل درجا و همزمان (on-the-fly) هیپ کد را فراهم می‌کند. فرآیند تحلیل به دو بخش تقسیم می‌شود. بخش اول کل هیپ کد را بررسی کرده و تمام اطلاعاتی را که مفید یا مهم تلقی می‌شوند تجمیع می‌کند. بخش دوم شامل چندین مرحله مستقل است که اطلاعات جمع‌آوری‌شده را با تاکید بر جنبه‌های مختلف داده‌ها چاپ می‌کند. جمع‌آوری داده‌ها و چاپ به صورت «بر اساس تقاضا» (on request) انجام می‌شود.

درخواست‌ها برای تحلیل بلادرنگ و همزمان را می‌توان با دستور زیر صادر کرد:

jcmd pid Compiler.CodeHeap_Analytics [function] [granularity]

اگر فقط به وضعیت هیپ کد پس از اجرای یک بار کاری نمونه علاقه‌مند هستید، می‌توانید از گزینه خط فرمان زیر استفاده کنید:

-Xlog:codecache=Trace

برای مشاهده وضعیت هیپ کد در زمان بروز وضعیت «CodeCache full» (پر شدن کش کد)، ماشین مجازی را با گزینه خط فرمان زیر راه‌اندازی کنید:

-Xlog:codecache=Debug

برای توضیحات دقیق درباره قابلیت تحلیل وضعیت هیپ کد، توابع پشتیبانی‌شده و گزینه‌های دانه‌بندی (granularity)، به CodeHeap State Analytics (OpenJDK) [https://bugs.openjdk.java.net/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf] مراجعه کنید.

شما از گزینه -Xlog برای پیکربندی یا فعال‌سازی لاگ با چارچوب لاگ یکپارچه ماشین مجازی جاوا (JVM) استفاده می‌کنید.

-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

-Xlog:directive

ترکیبی از تگ‌ها و سطوح را به صورت tag1[+tag2...][*][=level][,...] مشخص می‌کند. مگر اینکه کاراکتر عمومی (*) مشخص شده باشد، فقط پیام‌های لاگی که دقیقاً با تگ‌های مشخص‌شده برچسب خورده‌اند مطابقت داده می‌شوند. بخش تگ‌ها و سطوح -Xlog (-Xlog Tags and Levels) را ببینید.
نوع خروجی را تنظیم می‌کند. در صورت حذف نوع output، مقدار پیش‌فرض stdout خواهد بود. بخش خروجی -Xlog (-Xlog Output) را ببینید.
خروجی را برای استفاده از یک مجموعه سفارشی از تزیین‌کننده‌ها پیکربندی می‌کند. حذف decorators به طور پیش‌فرض روی uptime، level و tags تنظیم می‌شود. بخش تزیینات و متادیتای لاگ (Decorations) را ببینید.
گزینه‌های خروجی لاگ -Xlog را تنظیم می‌کند.
یک گزینه سراسری یا زیردستور: help، disable، async

چارچوب لاگ یکپارچه ماشین مجازی جاوا (JVM) یک سیستم لاگ مشترک را برای تمام اجزای JVM فراهم می‌کند. لاگ جمع‌آوری زباله (GC) برای JVM تغییر یافته است تا از چارچوب جدید لاگ استفاده کند. نگاشت فلگ‌های قدیمی GC به پیکربندی متناظر جدید Xlog در بخش تبدیل فلگ‌های لاگ GC به Xlog شرح داده شده است. علاوه بر این، لاگ زمان اجرا (runtime logging) نیز تغییر یافته است تا از چارچوب لاگ یکپارچه JVM استفاده کند. نگاشت فلگ‌های موروثی لاگ زمان اجرا به پیکربندی متناظر جدید Xlog در بخش تبدیل فلگ‌های لاگ زمان اجرا به Xlog توضیح داده شده است.

موارد زیر یک مرجع سریع برای دستور -Xlog و ساختار دستوری گزینه‌ها ارائه می‌دهد:

لاگ JVM را در سطح info فعال می‌کند.
ساختار دستوری استفاده از -Xlog و تگ‌ها، سطوح و تزیین‌کننده‌های موجود را همراه با خطوط فرمان نمونه و توضیحات چاپ می‌کند.
تمام لاگ‌ها را خاموش کرده و تمام پیکربندی چارچوب لاگ از جمله پیکربندی پیش‌فرض برای هشدارها و خطاها را پاک می‌کند.
چندین آرگومان را به ترتیبی که در خط فرمان ظاهر می‌شوند اعمال می‌کند. چندین آرگومان -Xlog برای یک خروجی یکسان، یکدیگر را به ترتیب مشخص‌شده بازنویسی (override) می‌کنند.

گزینه option به صورت زیر تنظیم می‌شود:

[tag-selection][:[output][:[decorators][:output-options]]]

حذف tag-selection به طور پیش‌فرض روی مجموعه تگ all و سطح info تنظیم می‌شود.

tag[+...] all

تگ all یک متاتگ متشکل از تمام مجموعه‌های تگ موجود است. ستاره * در تعریف مجموعه تگ نشان‌دهنده تطابق الگوی عام (wildcard) است. تطابق با کاراکتر عام تمام مجموعه‌های تگی را که حداقل شامل تگ‌های مشخص‌شده هستند انتخاب می‌کند. بدون کاراکتر عام، فقط تطابق‌های دقیق از مجموعه‌های تگ مشخص‌شده انتخاب می‌شوند.

output-options عبارت است از

filecount=file-count filesize=حجم فایل با پسوند اختیاری K، M یا G

هنگامی که گزینه -Xlog و هیچ چیز دیگری در خط فرمان مشخص نشده باشد، از پیکربندی پیش‌فرض استفاده می‌شود. پیکربندی پیش‌فرض تمام پیام‌هایی را که سطح آن‌ها با warning یا error مطابقت دارد، صرف‌نظر از اینکه پیام با چه تگ‌هایی مرتبط است، ثبت می‌کند. پیکربندی پیش‌فرض معادل وارد کردن دستور زیر در خط فرمان است:

-Xlog:all=warning:stdout:uptime,level,tags

لاگ را می‌توان در زمان اجرا از طریق دستورات تشخیصی (با ابزار jcmd) نیز کنترل کرد. هر چیزی را که بتوان در خط فرمان مشخص کرد، می‌توان به صورت پویا با دستور VM.log نیز مشخص نمود. از آنجا که دستورات تشخیصی به طور خودکار به عنوان MBeanها در معرض نمایش قرار می‌گیرند، می‌توانید از JMX برای تغییر پیکربندی لاگ در زمان اجرا استفاده کنید.

هر پیام لاگ دارای یک سطح و یک مجموعه تگ مرتبط با خود است. سطح پیام متناظر با جزئیات آن است و مجموعه تگ متناظر با محتوای پیام یا اینکه کدام جزء JVM را در بر می‌گیرد (مانند gc، jit یا os) می‌باشد. نگاشت فلگ‌های GC به پیکربندی Xlog در بخش تبدیل فلگ‌های لاگ GC به Xlog شرح داده شده است. نگاشت فلگ‌های موروثی لاگ زمان اجرا به پیکربندی متناظر Xlog در بخش تبدیل فلگ‌های لاگ زمان اجرا به Xlog توضیح داده شده است.

سطوح لاگ موجود:

•
off
•
trace
•
debug
•
info
•
warning
•
error

تگ‌های لاگ موجود:

به معنای واقعی کلمه ده‌ها تگ لاگ وجود دارد که در ترکیب‌های مناسب، طیف وسیعی از خروجی‌های لاگ را فعال می‌کنند. مجموعه کامل تگ‌های لاگ موجود را می‌توان با استفاده از -Xlog:help مشاهده کرد. مشخص کردن all به جای یک ترکیب تگ با تمام ترکیب‌های تگ مطابقت پیدا می‌کند.

گزینه -Xlog از انواع خروجی‌های زیر پشتیبانی می‌کند:

•
stdout --- خروجی را به خروجی استاندارد (stdout) ارسال می‌کند
•
stderr --- خروجی را به خطای استاندارد (stderr) ارسال می‌کند
•
file=filename --- خروجی را به فایل(های) متنی ارسال می‌کند.

هنگام استفاده از file=filename، مشخص کردن %p و/یا %t در نام فایل به ترتیب به PID مربوط به JVM و برچسب زمانی راه‌اندازی باز می‌شود. همچنین می‌توانید فایل‌های متنی را برای مدیریت چرخش فایل (file rotation) بر اساس اندازه فایل و تعداد فایل‌های در چرخش پیکربندی کنید. برای مثال، برای چرخش فایل لاگ در هر ۱۰ مگابایت و نگهداری ۵ فایل در چرخش، گزینه‌های filesize=10M, filecount=5 را مشخص کنید. اندازه هدف فایل‌ها تضمین نمی‌شود که دقیق باشد و صرفاً یک مقدار تقریبی است. فایل‌ها به طور پیش‌فرض با حداکثر ۵ فایل چرخشی با اندازه هدف ۲۰ مگابایت چرخش می‌یابند، مگر اینکه خلاف آن پیکربندی شود. مشخص کردن filecount=0 به این معنی است که فایل لاگ نباید چرخش یابد. احتمال بازنویسی روی فایل لاگ از پیش موجود وجود دارد.

به‌طور پیش‌فرض پیام‌های لاگ به صورت همگام (synchronously) خروجی داده می‌شوند؛ یعنی هر پیام لاگ هنگام فراخوانی لاگ در خروجی تعیین‌شده نوشته می‌شود. اما می‌توانید به جای آن با مشخص کردن گزینه زیر از حالت لاگ ناهمگام (asynchronous) استفاده کنید:

تمام لاگ‌ها را به صورت ناهمگام می‌نویسد.

در حالت لاگ ناهمگام، محل‌های ثبت لاگ تمام پیام‌های لاگ را در یک بافر میانی صف‌بندی می‌کنند و یک نخ (thread) مستقل مسئول تخلیه (flush) آن‌ها به خروجی‌های مربوطه است. بافر میانی محدود (bounded) است. در صورت پر شدن بافر، پیام در حال صف‌بندی یا دور انداخته می‌شود (async:drop)، یا نخ‌های لاگ متوقف (stalled) می‌شوند تا نخ تخلیه‌کننده برسد (async:stall). اگر حالت خاصی انتخاب نشود، به‌طور پیش‌فرض async:drop انتخاب می‌شود. عملیات نوشتن ورودی‌های لاگ در حالت async:drop تضمین شده است که غیرمسدودکننده (non-blocking) باشد.

گزینه -XX:AsyncLogBufferSize=N بودجه حافظه را بر حسب بایت برای بافر میانی مشخص می‌کند. مقدار پیش‌فرض باید به اندازه کافی بزرگ باشد تا پاسخگوی اکثر موارد باشد. کاربران در صورت نیاز می‌توانند یک مقدار سفارشی ارائه دهند تا در صورت تمایل، سربار حافظه را با دقت لاگ مبادله کنند.

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


[6.567s][info][gc,old] Old collection complete

حذف decorators به طور پیش‌فرض روی uptime، level و tags تنظیم می‌شود. تزیین‌کننده none خاص است و برای خاموش کردن تمام تزیینات استفاده می‌شود.

تزیین‌کننده‌های time (t)، utctime (utc)، uptime (u)، timemillis (tm)، uptimemillis (um)، timenanos (tn)، uptimenanos (un)، hostname (hn)، pid (p)، tid (ti)، level (l) و tags (tg) را نیز می‌توان به عنوان none برای نداشتن هیچ تزیینی مشخص کرد.

تزیینات توضیحات
time یا t زمان و تاریخ جاری در قالب ISO-8601.
utctime یا utc زمان هماهنگ جهانی (UTC).
uptime یا u زمان سپری‌شده از زمان شروع JVM بر حسب ثانیه و میلی‌ثانیه. برای مثال، 6.567s.
timemillis یا tm همان مقداری که توسط System.currentTimeMillis() تولید می‌شود.
uptimemillis یا um میلی‌ثانیه‌های سپری‌شده از زمان راه‌اندازی JVM.
timenanos یا tn همان مقداری که توسط System.nanoTime() تولید می‌شود.
uptimenanos یا un نانوثانیه‌های سپری‌شده از زمان راه‌اندازی JVM.
hostname یا hn نام میزبان (hostname).
pid یا p شناسه فرآیند (process identifier).
tid یا ti شناسه رشته (thread identifier).
level یا l سطح مرتبط با پیام لاگ.
tags یا tg مجموعه تگ‌های مرتبط با پیام لاگ.

پرچم قدیمی جمع‌آوری زباله (GC) پیکربندی Xlog توضیحات
G1PrintHeapRegions -Xlog:gc+region=trace قابل اعمال نیست
GCLogFileSize پیکربندی در دسترس نیست چرخش فایل‌های لاگ توسط چارچوب مدیریت می‌شود.
NumberOfGCLogFiles قابل اعمال نیست چرخش فایل‌های لاگ توسط چارچوب مدیریت می‌شود.
PrintAdaptiveSizePolicy -Xlog:gc+ergo*=level برای اکثر اطلاعات از level برابر با debug استفاده کنید، یا از level برابر با trace برای تمام مواردی که برای PrintAdaptiveSizePolicy لاگ می‌شد استفاده نمایید.
PrintGC -Xlog:gc قابل اعمال نیست
PrintGCApplicationConcurrentTime -Xlog:safepoint توجه داشته باشید که PrintGCApplicationConcurrentTime و PrintGCApplicationStoppedTime با همان تگ لاگ می‌شوند و در سیستم لاگ جدید از یکدیگر تفکیک نشده‌اند.
PrintGCApplicationStoppedTime -Xlog:safepoint توجه داشته باشید که PrintGCApplicationConcurrentTime و PrintGCApplicationStoppedTime با همان تگ لاگ می‌شوند و در سیستم لاگ جدید تفکیک نشده‌اند.
PrintGCCause قابل اعمال نیست علت GC اکنون همیشه لاگ می‌شود.
PrintGCDateStamps قابل اعمال نیست برچسب‌های تاریخ توسط چارچوب لاگ می‌شوند.
PrintGCDetails -Xlog:gc* قابل اعمال نیست
PrintGCID قابل اعمال نیست شناسه GC اکنون همیشه لاگ می‌شود.
PrintGCTaskTimeStamps -Xlog:gc+task*=debug قابل اعمال نیست
PrintGCTimeStamps قابل اعمال نیست برچسب‌های زمان توسط چارچوب لاگ می‌شوند.
PrintHeapAtGC -Xlog:gc+heap=trace قابل اعمال نیست
PrintReferenceGC -Xlog:gc+ref*=debug توجه داشته باشید که در سیستم لاگ قدیمی، PrintReferenceGC تنها در صورتی اثر داشت که PrintGCDetails نیز فعال شده باشد.
PrintStringDeduplicationStatistics -Xlog:gc+stringdedup*=debug قابل اعمال نیست
PrintTenuringDistribution -Xlog:gc+age*=level برای مرتبط‌ترین اطلاعات از level برابر با debug استفاده کنید، یا از level برابر با trace برای تمام مواردی که برای PrintTenuringDistribution لاگ می‌شد استفاده نمایید.
UseGCLogFileRotation قابل اعمال نیست چرخش فایل‌های لاگ توسط چارچوب مدیریت می‌شود.

این پرچم‌های قدیمی دیگر شناسایی نمی‌شوند و در صورت استفاده مستقیم باعث بروز خطا خواهند شد. به‌جای آن‌ها از معادل لاگ یکپارچه (Unified Logging) آن‌ها استفاده کنید.

پرچم قدیمی زمان اجرا پیکربندی Xlog توضیحات
TraceExceptions -Xlog:exceptions=info قابل اعمال نیست
TraceClassLoading -Xlog:class+load=level از level=info برای اطلاعات عادی، یا از level=debug برای اطلاعات تکمیلی استفاده کنید. در نحو لاگ یکپارچه، -verbose:class معادل -Xlog:class+load=info,class+unload=info است.
TraceClassLoadingPreorder -Xlog:class+preorder=debug قابل اعمال نیست
TraceClassUnloading -Xlog:class+unload=level از level=info برای اطلاعات عادی، یا از level=trace برای اطلاعات تکمیلی استفاده کنید. در نحو لاگ یکپارچه، -verbose:class معادل -Xlog:class+load=info,class+unload=info است.
VerboseVerification -Xlog:verification=info قابل اعمال نیست
TraceClassPaths -Xlog:class+path=info قابل اعمال نیست
TraceClassResolution -Xlog:class+resolve=debug قابل اعمال نیست
TraceClassInitialization -Xlog:class+init=info قابل اعمال نیست
TraceLoaderConstraints -Xlog:class+loader+constraints=info قابل اعمال نیست
TraceClassLoaderData -Xlog:class+loader+data=level از level=debug برای اطلاعات عادی یا از level=trace برای اطلاعات تکمیلی استفاده کنید.
TraceSafepointCleanupTime -Xlog:safepoint+cleanup=info قابل اعمال نیست
TraceSafepoint -Xlog:safepoint=debug قابل اعمال نیست
TraceMonitorInflation -Xlog:monitorinflation=debug قابل اعمال نیست
TraceBiasedLocking -Xlog:biasedlocking=level از level=info برای اطلاعات عادی، یا از level=trace برای اطلاعات تکمیلی استفاده کنید.
TraceRedefineClasses -Xlog:redefine+class*=level سطوح level=info، debug و trace مقادیر فزاینده‌ای از اطلاعات را ارائه می‌دهند.

در ادامه مثال‌هایی از -Xlog آورده شده است.

تمام پیام‌ها را با استفاده از سطح info به stdout همراه با تزئینات uptime، levels و tags لاگ می‌کند. این معادل استفاده از دستور زیر است:

-Xlog:all=info:stdout:uptime,levels,tags

پیام‌های برچسب‌خورده با تگ gc را با استفاده از سطح info به stdout لاگ می‌کند. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning برقرار است.
پیام‌های برچسب‌خورده با تگ‌های gc یا safepoint را، هر دو با استفاده از سطح info، به stdout همراه با تزئینات پیش‌فرض لاگ می‌کند. پیام‌های برچسب‌خورده با هر دو تگ gc و safepoint لاگ نخواهند شد.
پیام‌های برچسب‌خورده با هر دو تگ gc و ref را با استفاده از سطح debug به stdout همراه با تزئینات پیش‌فرض لاگ می‌کند. پیام‌هایی که تنها با یکی از این دو تگ برچسب خورده‌اند لاگ نخواهند شد.
پیام‌های برچسب‌خورده با تگ gc را با استفاده از سطح debug در فایلی به نام gc.txt بدون هیچ تزئینی لاگ می‌کند. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning همچنان برقرار است.
پیام‌های برچسب‌خورده با تگ gc را با استفاده از سطح trace در مجموعه‌ای چرخشی از ۵ فایل با اندازه ۱ مگابایت با نام پایه gctrace.txt لاگ کرده و از تزئینات uptimemillis و pid استفاده می‌کند.

پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning همچنان برقرار است.

پیام‌های برچسب‌خورده با تگ gc را با استفاده از سطح پیش‌فرض 'info' به خروجی پیش‌فرض stdout لاگ کرده و از تزئینات uptime و tid استفاده می‌کند. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning همچنان برقرار است.
پیام‌های برچسب‌خورده با حداقل تگ gc را با استفاده از سطح info لاگ می‌کند، اما لاگ پیام‌های برچسب‌خورده با safepoint را خاموش می‌نماید. پیام‌های برچسب‌خورده با هر دو تگ gc و safepoint لاگ نخواهند شد.
تمام لاگ‌ها، شامل هشدارها و خطاها را غیرفعال کرده و سپس پیام‌های برچسب‌خورده با safepoint را با استفاده از سطح trace در فایل safepointtrace.txt فعال می‌کند. پیکربندی پیش‌فرض اعمال نمی‌شود، زیرا خط فرمان با -Xlog:disable شروع شده است.

در ادامه چند مثال پیچیده از استفاده از گزینه -Xlog شرح داده شده است.

پیام‌های برچسب‌خورده با حداقل تگ‌های gc و class را با استفاده از سطح debug به stdout لاگ می‌کند. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning همچنان برقرار است.
پیام‌های برچسب‌خورده با حداقل تگ‌های gc و meta را با استفاده از سطح trace در فایل metatrace.txt لاگ می‌کند، اما تمام پیام‌های برچسب‌خورده با class را خاموش می‌نماید. پیام‌های برچسب‌خورده با gc، meta و class لاگ نخواهند شد چرا که class* روی خاموش تنظیم شده است. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning برقرار است به جز مواردی که شامل class هستند.
پیام‌های برچسب‌خورده با دقیقاً تگ‌های gc و meta را با استفاده از سطح trace به stdout لاگ می‌کند. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning همچنان برقرار است.
پیام‌های برچسب‌خورده با حداقل تگ‌های gc، class و heap را با استفاده از سطح trace به stdout لاگ می‌کند، اما فقط پیام‌های برچسب‌خورده با meta را با سطح مربوطه لاگ می‌نماید. پیکربندی پیش‌فرض برای سایر پیام‌ها در سطح warning برقرار است به جز مواردی که شامل threads هستند.

شما از مقادیر ارائه‌شده به تمام پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) برای اعتبارسنجی استفاده می‌کنید و اگر مقدار ورودی نامعتبر یا خارج از محدوده باشد، پیام خطای مناسبی نمایش داده می‌شود.

چه به‌صورت ارگونومیک، در خط فرمان، توسط یک ابزار ورودی یا از طریق APIها (به‌عنوان مثال، کلاس‌های موجود در بسته java.lang.management) تنظیم شده باشند، مقادیر ارائه‌شده به تمام پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) اعتبارسنجی می‌شوند. ارگونومی در راهنمای تنظیم جمع‌آوری زباله ماشین مجازی HotSpot ویرایش استاندارد پلتفرم جاوا شرح داده شده است.

محدوده و محدودیت‌ها یا زمانی که تمام پرچم‌ها مقادیر خود را در طول مقداردهی اولیه JVM تنظیم می‌کنند و یا زمانی که مقدار یک پرچم در زمان اجرا تغییر می‌کند (به‌عنوان مثال با استفاده از ابزار jcmd) اعتبارسنجی می‌شوند. اگر مقداری بررسی محدوده یا محدودیت را نقض کند، JVM خاتمه می‌یابد و پیام خطای مناسبی در جریان خطا چاپ می‌شود.

به‌عنوان مثال، اگر یک پرچم بررسی محدوده یا محدودیت را نقض کند، JVM با خطا خارج می‌شود:


java -XX:AllocatePrefetchStyle=5 -version
intx AllocatePrefetchStyle=5 is outside the allowed range [ 0 ... 3 ]
Improperly specified VM option 'AllocatePrefetchStyle=5'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

پرچم -XX:+PrintFlagsRanges محدوده تمام پرچم‌ها را چاپ می‌کند. این پرچم امکان آزمایش خودکار پرچم‌ها را بر اساس مقادیر ارائه‌شده توسط محدوده‌ها فراهم می‌کند. برای پرچم‌هایی که محدوده‌های آن‌ها مشخص شده است، نوع، نام و محدوده واقعی در خروجی چاپ می‌شود.

به‌عنوان مثال:


intx   ThreadStackSize [ 0 ... 9007199254740987 ] {pd product}

برای پرچم‌هایی که محدوده آن‌ها مشخص نشده است، مقادیر در خروجی نمایش داده نمی‌شوند. به‌عنوان مثال:


size_t NewSize         [   ...                  ] {product}

این امر به شناسایی پرچم‌هایی که نیاز به پیاده‌سازی دارند کمک می‌کند. چارچوب آزمایش خودکار می‌تواند پرچم‌هایی را که فاقد مقدار هستند و پیاده‌سازی نشده‌اند نادیده بگیرد.

شما از صفحات بزرگ (Large Pages) که به عنوان صفحات غول‌پیکر (Huge Pages) نیز شناخته می‌شوند، به‌عنوان صفحات حافظه‌ای استفاده می‌کنید که به‌طور قابل توجهی بزرگتر از اندازه استاندارد صفحه حافظه هستند (که بسته به پردازنده و سیستم‌عامل متفاوت است). صفحات بزرگ بافرهای ترجمه آدرس (Translation-Lookaside Buffers / TLB) پردازنده را بهینه‌سازی می‌کنند.

یک بافر ترجمه آدرس (TLB) یک کش ترجمه صفحه است که ترجمه‌های آدرس مجازی به فیزیکی اخیراً استفاده‌شده را نگه می‌دارد. بافر TLB یک منبع سیستمی کمیاب است. نبود داده در TLB (اصطلاحاً TLB miss) می‌تواند پرهزینه باشد زیرا پردازنده باید از جدول صفحه سلسله‌مراتبی بخواند که ممکن است نیاز به چندین دسترسی به حافظه داشته باشد. با استفاده از اندازه صفحه حافظه بزرگتر، یک ورودی TLB می‌تواند محدوده حافظه بزرگتری را نشان دهد. این امر منجر به فشار کمتر بر روی TLB می‌شود و برنامه‌های پرمصرف از نظر حافظه ممکن است کارایی بهتری داشته باشند.

با این حال، استفاده از صفحات بزرگ می‌تواند بر کارایی سیستم تأثیر منفی بگذارد. به‌عنوان مثال، هنگامی که مقدار زیادی از حافظه توسط یک برنامه پین (Pin) می‌شود، ممکن است کمبود حافظه معمولی ایجاد کند و باعث صفحه‌بندی (Paging) بیش از حد در سایر برنامه‌ها شده و کل سیستم را کند کند. همچنین، سیستمی که برای مدت طولانی روشن بوده است می‌تواند تکه‌تکه‌شدگی (Fragmentation) بیش از حد ایجاد کند که ممکن است رزرو حافظه کافی برای صفحات بزرگ را غیرممکن سازد. هنگامی که این اتفاق می‌افتد، سیستم‌عامل یا JVM به استفاده از صفحات معمولی برمی‌گردند.

لینوکس و ویندوز از صفحات بزرگ پشتیبانی می‌کنند.

لینوکس از نسخه 2.6 از صفحات بزرگ پشتیبانی می‌کند. برای بررسی اینکه آیا محیط شما از صفحات بزرگ پشتیبانی می‌کند، دستور زیر را امتحان کنید:


# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
...
Hugepagesize: 2048 kB

اگر خروجی شامل مواردی با پیشوند "Huge" باشد، سیستم شما از صفحات بزرگ پشتیبانی می‌کند. مقادیر ممکن است بسته به محیط متفاوت باشد. فیلد Hugepagesize اندازه پیش‌فرض صفحه بزرگ را در محیط شما نشان می‌دهد و سایر فیلدها جزئیات صفحات بزرگ با این اندازه را نمایش می‌دهند. هسته‌های جدیدتر از چندین اندازه صفحه بزرگ پشتیبانی می‌کنند. برای فهرست کردن اندازه‌های پشتیبانی‌شده، دستور زیر را اجرا کنید:


# ls /sys/kernel/mm/hugepages/
hugepages-1048576kB  hugepages-2048kB

محیط بالا از صفحات بزرگ 2 مگابایت و 1 گیگابایت پشتیبانی می‌کند، اما باید پیکربندی شوند تا JVM بتواند از آن‌ها استفاده کند. هنگام استفاده از صفحات بزرگ و عدم فعال‌سازی صفحات بزرگ شفاف (گزینه -XX:+UseTransparentHugePages)، تعداد صفحات بزرگ باید از قبل تخصیص یابد. به‌عنوان مثال، برای فعال کردن 8 گیگابایت حافظه با صفحات بزرگ 2 مگابایتی، با کاربر root وارد شوید و دستور زیر را اجرا کنید:

# echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

همیشه توصیه می‌شود پس از درخواست، مقدار nr_hugepages را بررسی کنید تا مطمئن شوید هسته توانسته تعداد صفحات بزرگ درخواستی را تخصیص دهد.

هنگام استفاده از گزینه -XX:+UseSHM برای فعال‌سازی صفحات بزرگ، همچنین باید مطمئن شوید که پارامتر SHMMAX به‌گونه‌ای پیکربندی شده است که اجازه تخصیص قطعات حافظه مشترک به اندازه کافی بزرگ را می‌دهد. برای مجاز ساختن حداکثر قطعه اشتراکی 8 گیگابایت، با کاربر root وارد شوید و دستور زیر را اجرا کنید:

# echo 8589934592 > /proc/sys/kernel/shmmax

در برخی محیط‌ها این کار لازم نیست زیرا مقدار پیش‌فرض به اندازه کافی بزرگ است، اما مهم است که اطمینان حاصل کنید مقدار آن به اندازه کافی بزرگ است تا مقدار حافظه در نظر گرفته شده برای صفحات بزرگ را در خود جای دهد.

نکته: مقادیر موجود در /proc و /sys پس از راه‌اندازی مجدد سیستم بازنشانی می‌شوند، بنابراین ممکن است بخواهید آن‌ها را در یک اسکریپت مقداردهی اولیه (به‌عنوان مثال rc.local یا sysctl.conf) تنظیم کنید.

اگر پارامترهای هسته سیستم‌عامل را برای فعال‌سازی استفاده از صفحات بزرگ پیکربندی کنید، فرایندهای جاوا ممکن است صفحات بزرگ را برای هیپ جاوا و همچنین سایر نواحی داخلی تخصیص دهند، به‌عنوان مثال:

•
کش کد (Code cache)
•
بیت‌مپ‌های نشانه‌گذاری (Marking bitmaps)

در نتیجه، اگر پارامتر nr_hugepages را برابر با اندازه هیپ جاوا پیکربندی کنید، ممکن است JVM همچنان در تخصیص هیپ با استفاده از صفحات بزرگ شکست بخورد زیرا سایر نواحی مانند کش کد ممکن است قبلاً بخشی از صفحات بزرگ پیکربندی‌شده را مصرف کرده باشند.

برای استفاده از پشتیبانی صفحات بزرگ در ویندوز، مدیر سیستم ابتدا باید امتیازات اضافی را به کاربری که برنامه را اجرا می‌کند اختصاص دهد:

1.
گزینه Control Panel، سپس Administrative Tools و سپس Local Security Policy را انتخاب کنید.
2.
گزینه Local Policies و سپس User Rights Assignment را انتخاب کنید.
3.
روی Lock pages in memory دوبار کلیک کرده و کاربران یا گروه‌ها را اضافه کنید.
4.
سیستم خود را مجدداً راه‌اندازی (Reboot) کنید.

توجه داشته باشید که این مراحل حتی اگر مدیر سیستم برنامه را اجرا کند نیز الزامی است، زیرا مدیران سیستم به‌طور پیش‌فرض امتیاز قفل کردن صفحات در حافظه را ندارند.

قابلیت اشتراک‌گذاری داده‌های کلاس برنامه (AppCDS) کلاس‌های مورد استفاده برنامه‌های شما را در یک فایل آرشیو ذخیره می‌کند. از آنجا که این کلاس‌ها در قالبی ذخیره می‌شوند که می‌توانند بسیار سریع بارگذاری شوند (در مقایسه با کلاس‌های ذخیره‌شده در یک فایل JAR)، AppCDS می‌تواند زمان راه‌اندازی برنامه‌های شما را بهبود بخشد. علاوه بر این، AppCDS می‌تواند با به اشتراک گذاشتن بخش‌هایی از این کلاس‌ها در چندین فرایند، ردپای حافظه زمان اجرا را کاهش دهد.

کلاس‌ها در آرشیو CDS در قالبی بهینه‌سازی‌شده ذخیره می‌شوند که حدود ۲ تا ۵ برابر بزرگتر از کلاس‌های ذخیره‌شده در فایل‌های JAR یا ایمیج زمان اجرای JDK است. بنابراین، ایده خوبی است که فقط کلاس‌هایی را که واقعاً توسط برنامه شما استفاده می‌شوند آرشیو کنید. این کلاس‌ها معمولاً تنها بخش کوچکی از تمام کلاس‌های موجود هستند. برای مثال، برنامه شما ممکن است تنها از چند API ارائه‌شده توسط یک کتابخانه بزرگ استفاده کند.

به‌طور پیش‌فرض در بیشتر توزیع‌های JDK، مگر اینکه -Xshare:off مشخص شده باشد، JVM با یک آرشیو CDS پیش‌فرض راه‌اندازی می‌شود که معمولاً در مسیر JAVA_HOME/lib/server/classes.jsa (یا JAVA_HOME\bin\server\classes.jsa در ویندوز) قرار دارد. این آرشیو حاوی حدود ۱۳۰۰ کلاس کتابخانه اصلی است که توسط بیشتر برنامه‌ها استفاده می‌شوند.

برای استفاده از CDS برای مجموعه دقیق کلاس‌های استفاده‌شده توسط برنامه خود، می‌توانید از گزینه -XX:SharedArchiveFile استفاده کنید که ساختار کلی زیر را دارد:

-XX:SharedArchiveFile=<static_archive>:<dynamic_archive>

  • بخش <static_archive> آرشیو پیش‌فرض CDS را بازنویسی می‌کند.
  • بخش <dynamic_archive> کلاس‌های اضافی را فراهم می‌کند که می‌توانند علاوه بر کلاس‌های موجود در <static_archive> بارگذاری شوند.
  • در ویندوز، جداکننده مسیر فوق : باید با ; جایگزین شود.

نام‌های «ایستا» و «پویا» به دلایل تاریخی استفاده می‌شوند. آرشیو پویا، با اینکه هنوز مفید است، نسبت به آرشیو ایستای CDS از بهینه‌سازی‌های کمتری پشتیبانی می‌کند. اگر به دنبال مجموعه کامل بهینه‌سازی‌های CDS/AOT هستید، استفاده از حافظه پنهان AOT که در زیر شرح داده شده است را در نظر بگیرید.

ماشین مجازی JVM می‌تواند حداکثر از دو آرشیو استفاده کند. برای استفاده از تنها یک آرشیو تکی <static_archive>، می‌توانید بخش <dynamic_archive> را حذف کنید:

-XX:SharedArchiveFile=<static_archive>

برای راحتی، <dynamic_archive> مکان <static_archive> را ضبط می‌کند. بنابراین، می‌توانید <static_archive> را فقط با تعیین دستور زیر حذف کنید:

-XX:SharedArchiveFile=<dynamic_archive>

آرشیوهای CDS را می‌توان به‌صورت دستی با چندین روش ایجاد کرد:

  • -Xshare:dump
  • -XX:ArchiveClassesAtExit
  • jcmd VM.cds

یک عملیات مشترک در تمام این روش‌ها یک «اجرای آزمایشی» است که در آن برنامه را یک بار اجرا می‌کنید تا کلاس‌هایی که باید در آرشیو ذخیره شوند تعیین شوند.

مراحل زیر یک فایل آرشیو ایستای CDS ایجاد می‌کند که حاوی تمام کلاس‌های استفاده‌شده توسط برنامه test.Hello است.

1.
فهرستی از تمام کلاس‌های استفاده‌شده توسط برنامه test.Hello ایجاد کنید. دستور زیر فایلی به نام hello.classlist ایجاد می‌کند که حاوی فهرستی از تمام کلاس‌های استفاده‌شده توسط این برنامه است:

java -Xshare:off -XX:DumpLoadedClassList=hello.classlist -cp hello.jar test.Hello

مسیر کلاسی که با پارامتر -cp مشخص می‌شود باید فقط شامل فایل‌های JAR باشد.

2.
یک آرشیو ایستا به نام hello.jsa ایجاد کنید که حاوی تمام کلاس‌های موجود در hello.classlist است:

java -Xshare:dump -XX:SharedArchiveFile=hello.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar

3.
برنامه test.Hello را با آرشیو hello.jsa اجرا کنید:

java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello

4.
اختیاری بررسی کنید که برنامه test.Hello از کلاس موجود در آرشیو اشتراکی hello.jsa استفاده می‌کند:

java -XX:SharedArchiveFile=hello.jsa -cp hello.jar -Xlog:class+load test.Hello

خروجی این دستور باید شامل متن زیر باشد:

[info][class,load] test.Hello source: shared objects file

به‌طور پیش‌فرض، هنگامی که گزینه -Xshare:dump استفاده می‌شود، JVM در حالت فقط مفسر (مانند زمانی که گزینه -Xint مشخص شده باشد) اجرا می‌شود. این امر برای تولید خروجی قطعی (deterministic) در فایل آرشیو اشتراکی لازم است؛ یعنی دقیقاً همان آرشیو، بیت به بیت، در هر بار خروجی گرفتن تولید خواهد شد. با این حال، اگر خروجی قطعی مورد نیاز نباشد و یک classlist بزرگ داشته باشید، می‌توانید به‌طور صریح -Xmixed را به خط فرمان اضافه کنید تا کامپایلر JIT فعال شود. این کار ایجاد آرشیو را تسریع می‌بخشد.

مزایای آرشیوهای پویای CDS عبارتند از:

  • آن‌ها معمولاً فضای دیسک کمتری مصرف می‌کنند، زیرا نیازی به ذخیره کلاس‌هایی که از قبل در آرشیو ایستا وجود دارند ندارند.
  • آن‌ها با یک مرحله کمتر نسبت به آرشیو ایستای متناظر ایجاد می‌شوند.

مراحل زیر یک فایل آرشیو پویای CDS ایجاد می‌کند که حاوی کلاس‌های استفاده‌شده توسط برنامه test.Hello است، به استثنای مواردی که از قبل در آرشیو پیش‌فرض CDS قرار دارند.

1.
یک آرشیو پویای CDS به نام hello.jsa ایجاد کنید که حاوی تمام کلاس‌های موجود در hello.jar باشد که توسط برنامه test.Hello بارگذاری شده‌اند:

java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

2.
برنامه test.Hello را با آرشیو اشتراکی hello.jsa اجرا کنید:

java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello

3.
اختیاری مرحله ۴ از بخش قبلی را تکرار کنید تا مطمئن شوید برنامه test.Hello از کلاس موجود در آرشیو اشتراکی hello.jsa استفاده می‌کند.

همچنین می‌توان یک آرشیو پویای CDS را با یک آرشیو ایستای غیرپیش‌فرض CDS ایجاد کرد؛ برای مثال:

java -XX:SharedArchiveFile=base.jsa -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

برای اجرای برنامه با استفاده از این آرشیو پویای CDS:

java -XX:SharedArchiveFile=base.jsa:hello.jsa -cp hello.jar Hello

(در ویندوز، جداکننده مسیر فوق : باید با ; جایگزین شود)

همان‌طور که در بالا ذکر شد، نام آرشیو ایستا را می‌توان نادیده گرفت:

java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

دو بخش قبلی شما را ملزم می‌کردند که برای ایجاد یک آرشیو CDS، اسکریپت راه‌اندازی برنامه را تغییر دهید. گاهی اوقات این کار ممکن است دشوار باشد، برای مثال اگر مسیر کلاس برنامه توسط روال‌های پیچیده‌ای تنظیم شده باشد.

دستور jcmd VM.cds روشی کم‌دردسرتر برای ایجاد آرشیو CDS از طریق اتصال به یک پردازه در حال اجرای JVM فراهم می‌کند. می‌توانید یک آرشیو ایستا ایجاد کنید:

jcmd <pid> VM.cds static_dump my_static_archive.jsa

یا یک آرشیو پویا:

jcmd <pid> VM.cds dynamic_dump my_dynamic_archive.jsa

برای استفاده از فایل آرشیو حاصل در اجرای بعدی برنامه بدون دستکاری اسکریپت راه‌اندازی برنامه، می‌توانید از روش زیر استفاده کنید:

env JAVA_TOOL_OPTIONS=-XX:SharedArchiveFile=my_static_archive.jsa bash app_start.sh

نکته: برای استفاده از jcmd <pid> VM.cds dynamic_dump، پردازه JVM مشخص‌شده با <pid> باید با -XX:+RecordDynamicDumpInfo راه‌اندازی شده باشد، که آن را نیز می‌توان با همان روش به اسکریپت راه‌اندازی برنامه ارسال کرد:

env JAVA_TOOL_OPTIONS=-XX:+RecordDynamicDumpInfo bash app_start.sh

گزینه -XX:+AutoCreateSharedArchive روشی راحت‌تر برای ایجاد و استفاده از آرشیوهای CDS است. برخلاف روش‌های ایجاد دستی آرشیو CDS شرح‌داده‌شده در بخش قبلی، با -XX:+AutoCreateSharedArchive دیگر نیازی به یک اجرای آزمایشی مجزا نیست. به جای آن، می‌توانید همیشه برنامه را با همان خط فرمان اجرا کنید و به‌طور خودکار از مزایای CDS بهره‌مند شوید.

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

اگر فایل آرشیو مشخص‌شده وجود داشته باشد و توسط همان نسخه از JDK ایجاد شده باشد، به عنوان یک آرشیو پویا بارگذاری می‌شود؛ در غیر این صورت هنگام راه‌اندازی VM نادیده گرفته می‌شود.

هنگام خروج VM، اگر فایل آرشیو مشخص‌شده وجود نداشته باشد، ایجاد خواهد شد. اگر وجود داشته باشد اما با نسخه‌ای متفاوت (اما بعد از JDK 19) از JDK ایجاد شده باشد، جایگزین می‌شود. در هر دو حالت، آرشیو آماده خواهد بود تا دفعه بعد که JVM با همان خط فرمان راه‌اندازی می‌شود بارگذاری گردد.

اگر فایل آرشیو مشخص‌شده وجود داشته باشد اما توسط نسخه‌ای از JDK قبل از JDK 19 ایجاد شده باشد، نادیده گرفته می‌شود: نه در هنگام راه‌اندازی بارگذاری می‌شود و نه در هنگام خروج جایگزین می‌گردد.

توسعه‌دهندگان باید توجه داشته باشند که محتویات فایل آرشیو CDS مختص هر بیلد از JDK است. بنابراین اگر به بیلد متفاوتی از JDK سوئیچ کنید، -XX:+AutoCreateSharedArchive به‌طور خودکار آرشیو را متناسب با JDK بازتولید می‌کند. اگر قصد دارید از این ویژگی با یک آرشیو موجود استفاده کنید، باید مطمئن شوید که آرشیو حداقل با نسخه 19 از JDK ایجاد شده است.

  • نه مسیر کلاس (-classpath و -Xbootclasspath/a) و نه مسیر ماژول (-dule-path) نمی‌توانند شامل پوشه‌های غیرخالی باشند.
  • تنها فایل‌های مدولار JAR در -dule-path پشتیبانی می‌شوند. ماژول‌های بسته‌بندی‌نشده (exploded modules) پشتیبانی نمی‌شوند.
  • مسیر کلاس استفاده‌شده در زمان ایجاد آرشیو باید همانند مسیر کلاس استفاده‌شده در زمان اجرا (یا پیشوندی از آن) باشد. (چنین الزامی برای مسیر ماژول وجود ندارد.)
  • اگر هر یک از فایل‌های JAR در مسیر کلاس یا مسیر ماژول پس از ایجاد آرشیو تغییر یابند، آرشیو CDS نمی‌تواند بارگذاری شود.

گزینه‌های مرتبط با ماژول زیر توسط CDS پشتیبانی می‌شوند: -dule-path، -dule، -dd-modules و -\nable-native-access.

مقادیر این گزینه‌ها (در صورت تعیین)، هنگام ایجاد و استفاده از آرشیو CDS باید یکسان باشند. در غیر این صورت، اگر عدم تطابقی در هر یک از این گزینه‌ها وجود داشته باشد، آرشیو CDS ممکن است به‌طور جزئی یا کامل غیرفعال شود که منجر به کاهش عملکرد می‌گردد.

•
اگر گزینه AOTClassLinking (پایین را ببینید) در زمان ایجاد آرشیو CDS فعال بوده باشد، آرشیو CDS قابل استفاده نیست و پیام خطای زیر چاپ می‌شود:

CDS archive has aot-linked classes. It cannot be used when archived full module graph is not used

•
اگر گزینه AOTClassLinking در زمان ایجاد آرشیو CDS فعال نبوده باشد، آرشیو CDS قابل استفاده است، اما ویژگی «گراف ماژول آرشیوشده» غیرفعال خواهد شد. این می‌تواند منجر به افزایش زمان راه‌اندازی شود.

برای خطایابی و بررسی مشکلات گزینه‌های AOT، می‌توانید -Xlog:aot را به آرگومان‌های VM برنامه اضافه کنید. برای مثال، اگر -dd-modules jdk.jconsole هنگام ایجاد آرشیو مشخص شده باشد و -dd-modules jdk.incubator.vector در زمان اجرا مشخص شود، پیام‌های زیر ثبت خواهند شد:

Mismatched values for property jdk.module.addmods

runtime jdk.incubator.vector dump time jdk.jconsole

subgraph jdk.internal.module.ArchivedBootLayer cannot be used because full module graph is disabled

اگر هر یک از گزینه‌های VM شامل -pgrade-module-path، -atch-module
یا -t-modules مشخص شوند، CDS غیرفعال می‌شود. این بدان معناست که JVM بدون بارگذاری هیچ‌یک از آرشیوهای CDS اجرا خواهد شد. علاوه بر این، اگر سعی کنید یک آرشیو CDS را با مشخص کردن هر یک از این ۳ گزینه ایجاد نمایید، JVM خطا گزارش خواهد داد.

محیط JDK از بهینه‌سازی‌های کامپایل پیش از موعد (AOT) که می‌توانند پیش از اجرای یک برنامه انجام شوند پشتیبانی می‌کند. یک نمونه از آن، اشتراک‌گذاری داده‌های کلاس (CDS) است که در بالا شرح داده شد و کلاس‌ها را پیش از موعد تجزیه می‌کند. بهینه‌سازی‌های AOT می‌توانند کارایی زمان راه‌اندازی و گرم شدن (warm-up) برنامه‌های جاوا را بهبود بخشند.

حافظه پنهان پیش از موعد (AOT cache) یک ظرف نگهدارنده است که در JDK 24 برای ذخیره دست‌ساخته‌های تولیدشده توسط بهینه‌سازی‌های AOT معرفی شد. حافظه پنهان AOT در حال حاضر شامل کلاس‌های جاوا و اشیاء هیپ است. در نسخه‌های آینده JDK، حافظه پنهان AOT ممکن است شامل دست‌ساخته‌های اضافی مانند پروفایل‌های اجرا و متدهای کامپایل‌شده باشد.

یک حافظه پنهان AOT مختص ترکیبی از موارد زیر است:

  • یک برنامه خاص (همان‌طور که با -classpath، -jar یا -dule-path مشخص می‌شود).
  • یک نسخه مشخص از JDK.
  • یک معماری پردازنده و سیستم‌عامل خاص.

اگر هر یک از موارد فوق تغییر کند، باید حافظه پنهان AOT را دوباره ایجاد کنید.

استقرار حافظه پنهان AOT به سه فاز تقسیم می‌شود:

  • آموزش (Training): برنامه را با یک بار کاری نمونه اجرا می‌کنیم تا داده‌های آماری لازم برای تعیین اینکه چه دست‌ساخته‌هایی باید در حافظه پنهان AOT گنجانده شوند جمع‌آوری گردد. این داده‌ها در یک فایل پیکربندی AOT ذخیره می‌شوند.
  • سرهم‌بندی (Assembly): از فایل پیکربندی AOT برای تولید یک حافظه پنهان AOT استفاده می‌کنیم.
  • عملیاتی (Production): برنامه را به همراه حافظه پنهان AOT برای دستیابی به عملکرد بهتر در زمان راه‌اندازی و گرم شدن اجرا می‌کنیم.

حافظه پنهان AOT را می‌توان با گزینه‌های خط فرمان زیر استفاده کرد:

مکان حافظه پنهان AOT را مشخص می‌کند. پسوند استاندارد برای cachefile برابر .aot است. این گزینه نمی‌تواند همزمان با -XX:AOTCacheOutput استفاده شود.
این گزینه با تنظیمات AOTMode شامل on، create یا auto (پیش‌فرض) سازگار است. فایل cachefile در حالت‌های AOT برابر on و auto خوانده می‌شود و در حالت off نادیده گرفته می‌شود. فایل cachefile در حالت AOT برابر create نوشته می‌شود. در این حالت، این گزینه معادل -XX:AOTCacheOutput=cachefile است.
مکان حافظه پنهان AOT جهت نوشتن را مشخص می‌کند. پسوند استاندارد برای cachefile برابر .aot است. این گزینه نمی‌تواند همزمان با -XX:AOTCache استفاده شود.
این گزینه با تنظیمات AOTMode شامل record، create یا auto (پیش‌فرض) سازگار است.
فایل پیکربندی AOT را برای خواندن یا نوشتن توسط JVM مشخص می‌کند. پسوند استاندارد برای configfile برابر .aotconfig است.
این گزینه با تنظیمات AOTMode شامل record، create یا auto (پیش‌فرض) سازگار است. فایل configfile توسط حالت AOT برابر create خوانده شده و توسط سایر حالت‌های مرتبط نوشته می‌شود. اگر حالت AOT برابر auto باشد، باید AOTCacheOutput نیز حضور داشته باشد.
حالت AOT را برای این اجرا مشخص می‌کند. مقدار mode باید یکی از موارد زیر باشد: auto، off، record، create یا on.
•
auto: این حالت AOT پیش‌فرض است و در صورتی که گزینه -XX:AOTMode مشخص نشده باشد اعمال می‌شود. این حالت به‌طور خودکار حالت AOT را به صورت زیر روی record، on یا off تنظیم می‌کند:
  • اگر -XX:AOTCacheOutput=cachefile مشخص شده باشد، حالت AOT به record تغییر می‌یابد (یک اجرای آموزشی، با عملیات create متعاقب آن).
  • در غیر این صورت، اگر یک حافظه پنهان AOT قابل بارگذاری باشد، حالت AOT به on تغییر می‌یابد (یک اجرای عملیاتی).
  • در غیر این صورت، حالت AOT به off تغییر می‌یابد (یک اجرای عملیاتی بدون حافظه پنهان AOT).
  • off: از هیچ حافظه پنهان AOT استفاده نمی‌شود. سایر گزینه‌های خط فرمان AOT نادیده گرفته می‌شوند.
  • record: اجرای برنامه در فاز آموزش. حداقل یکی از گزینه‌های -XX:AOTConfiguration=configfile و/یا -XX:AOTCacheOutput=cachefile باید مشخص شود. اگر -XX:AOTConfiguration=configfile مشخص شده باشد، JVM داده‌های آماری را جمع‌آوری کرده و در configfile ذخیره می‌کند. اگر -XX:AOTConfiguration=configfile مشخص نشده باشد، JVM از یک نام فایل موقت استفاده می‌کند که ممکن است رشته AOTCacheOutput+".config" یا یک نام فایل موقت تازه وابسته به پیاده‌سازی باشد. اگر -XX:AOTCacheOutput=cachefile مشخص شده باشد، یک پردازه دوم JVM برای اجرای فاز سرهم‌بندی (Assembly) راه‌اندازی می‌شود تا دست‌ساخته‌های بهینه‌سازی را در cachefile بنویسد.

گزینه‌های اضافی JVM را می‌توان با استفاده از متغیر محیطی JDK_AOT_VM_OPTIONS، با همان قالبی که برای متغیر محیطی JAVA_TOOL_OPTIONS تعریف شده و توسط JVMTI مشخص شده است [https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#tooloptions] به پردازه دوم JVM ارسال کرد.

  • create: اجرای فاز سرهم‌بندی (Assembly). گزینه -XX:AOTConfiguration=configfile باید مشخص شود. ماشین مجازی JVM تاریخچه و آمارها را از configfile خوانده و دست‌ساخته‌های بهینه‌سازی را در cachefile می‌نویسد. توجه داشته باشید که خود برنامه در این فاز اجرا نمی‌شود.
  • on: اجرای برنامه در فاز عملیاتی (Production). اگر -XX:AOTCache=cachefile مشخص شده باشد، JVM تلاش می‌کند cachefile را به عنوان حافظه پنهان AOT بارگذاری کند. در غیر این صورت، JVM تلاش می‌کند یک آرشیو پیش‌فرض CDS را از مسیر نصب JDK به عنوان حافظه پنهان AOT بارگذاری نماید.

بارگذاری یک حافظه پنهان AOT می‌تواند به دلایل مختلفی با شکست مواجه شود:

  • شما تلاش می‌کنید حافظه پنهان AOT را با یک برنامه، نسخه JDK، یا سیستم‌عامل/پردازنده ناسازگار استفاده کنید.
  • فایل cachefile مشخص‌شده وجود ندارد یا قابل دسترسی نیست.
  • گزینه‌های ناسازگار JVM استفاده شده‌اند (برای مثال، برخی گزینه‌های خاص JVMTI).

از آنجا که حافظه پنهان AOT یک ویژگی بهینه‌سازی است، هیچ تضمینی وجود ندارد که با تمامی گزینه‌های ممکن JVM سازگار باشد. برای مشاهده فهرستی نمونه از سناریوهایی که ممکن است با حافظه پنهان AOT ناسازگار باشند، بخش Consistency of training and subsequent runs در JEP 483 [https://openjdk.org/jeps/483] را ببینید.

این سناریوها معمولاً شامل دستکاری دلخواه کلاس‌ها برای اهداف تشخیصی هستند و معمولاً به محیط‌های عملیاتی مربوط نمی‌شوند.

هنگامی که بارگذاری حافظه پنهان AOT با شکست مواجه می‌شود:

  • اگر AOTMode در اصل روی auto تنظیم شده بود، JVM اجرای خود را بدون استفاده از حافظه پنهان AOT ادامه می‌دهد. این حالت برای محیط‌های عملیاتی توصیه می‌شود، به ویژه زمانی که ممکن است کنترل کاملی روی خط فرمان نداشته باشید (مثلاً اسکریپت راه‌اندازی برنامه شما ممکن است به کاربران اجازه تزریق گزینه‌ها به خط فرمان را بدهد). این امر به برنامه شما امکان می‌دهد تا به‌درستی کار کند، هرچند ممکن است گاهی از حافظه پنهان AOT بهره‌مند نشود.
  • اگر AOTMode روی on تنظیم شده باشد، JVM یک پیام خطا چاپ کرده و بلافاصله خارج می‌شود. این حالت باید تنها به عنوان یک کمک خطایابی سریع (fail-fast) استفاده شود تا بررسی کنید آیا گزینه‌های خط فرمان شما با حافظه پنهان AOT سازگار هستند یا خیر. یک راهکار دیگر، اجرای برنامه با -XX:AOTMode=auto -Xlog:aot است تا ببینید آیا حافظه پنهان AOT قابل استفاده است یا خیر.
اگر این گزینه فعال باشد، JVM هنگام ایجاد حافظه پنهان AOT بهینه‌سازی‌های پیشرفته‌تری (مانند حل پیش از موعد دستورات invokedynamic) انجام می‌دهد. در نتیجه، برنامه شاهد بهبودهای بیشتری در عملکرد راه‌اندازی و گرم شدن خواهد بود. با این حال، یک حافظه پنهان AOT که با این گزینه ایجاد شده است، در صورتی که پارامترهای خط فرمان خاصی در فاز عملیاتی مشخص شوند قابل استفاده نخواهد بود. لطفاً برای بحث تفصیلی درباره -XX:+AOTClassLinking و محدودیت‌های آن، به JEP 483 [https://openjdk.org/jeps/483] مراجعه کنید.
هنگامی که -XX:AOTMode در خط فرمان استفاده شود، قابلیت AOTClassLinking به‌طور خودکار فعال می‌گردد. برای غیرفعال کردن آن، باید صراحتاً گزینه -XX:-AOTClassLinking را ارسال کنید. هنگامی که -XX:AOTMode در خط فرمان استفاده نشود، قابلیت AOTClassLinking به‌طور پیش‌فرض غیرفعال است تا سازگاری کامل با گزینه‌های سنتی CDS مانند -Xshare:dump فراهم شود.

اولین رخداد توالی ویژه %p در configfile و cachefile با شناسه پردازه (PID) مربوط به پردازه JVM که در خط فرمان راه‌اندازی شده جایگزین می‌شود، و به همین ترتیب اولین رخداد %t با برچسب زمانی راه‌اندازی JVM جایگزین می‌گردد. (پس از جایگزینی، برای جلوگیری از بروز مشکل در زیرپردازه‌ها، نباید هیچ رخداد دیگری از %p یا %t وجود داشته باشد.) برای مثال:

java -XX:AOTConfiguration=foo%p.aotconfig -XX:AOTCacheOutput=foo%p.aot -cp foo.jar Foo

دو فایل ایجاد خواهد کرد: foopid123.aotconfig و foopid123.aot، که در آن 123 شناسه پردازه JVM است که برنامه Foo را اجرا کرده است.

می‌توانید از گزینه‌های پیشرفته زمان اجرای جاوا برای بهینه‌سازی کارایی برنامه‌های خود استفاده کنید.

از دستورات و گزینه‌های پیشرفته زیر برای دستیابی به توان پردازشی بالاتر در برنامه خود استفاده کنید:

java -server -XX:+UseParallelGC -XX:+UseLargePages -Xmn10g -Xms26g -Xmx26g

از دستورات و گزینه‌های پیشرفته زیر برای دستیابی به زمان‌های پاسخ‌دهی کوتاه‌تر در برنامه خود استفاده کنید:

java -XX:+UseG1GC -XX:MaxGCPauseMillis=100

از گزینه‌های پیشرفته زمان اجرای زیر برای کوچک نگه داشتن هیپ جاوا و کاهش ردپای پویای برنامه‌های تعبیه‌شده استفاده کنید:

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

نکته: مقادیر پیش‌فرض برای این دو گزینه به ترتیب 70٪ و 40٪ است. از آنجا که ممکن است هنگام استفاده از این تنظیمات کوچک افت کارایی رخ دهد، باید با کاهش این تنظیمات تا حد امکان بدون ایجاد افت کارایی غیرقابل قبول، برای ردپای حافظه کوچک بهینه‌سازی کنید.

مقادیر خروج زیر معمولاً توسط راه‌انداز در هنگامی که راه‌انداز با آرگومان‌های نادرست فراخوانی می‌شود، خطاهای جدی رخ می‌دهد یا استثناهایی توسط JVM پرتاب می‌شود بازگردانده می‌شوند. با این حال، یک برنامه جاوا ممکن است با استفاده از فراخوانی API به‌صورت System.exit(exitValue) تصمیم بگیرد هر مقداری را بازگرداند. مقادیر عبارتند از:

•
0: اجرای موفقیت‌آمیز
•
>0: خطایی رخ داده است
2026 JDK 25.0.4.1