JAVA(1) JDK Commands JAVA(1)

java - اجرای یک برنامه جاوا

برای اجرای یک فایل کلاس:

java [options] mainclass [args ...]

برای اجرای کلاس اصلی در یک فایل JAR:

java [options] -jar jarfile [args ...]

برای اجرای کلاس اصلی در یک ماژول:

java [options] -m module[/mainclass] [args ...]

یا

java [options] --module module[/mainclass] [args ...]

برای اجرای یک برنامه تک‌فایلی کد منبع:

java [options] source-file [args ...]

اختیاری: گزینه‌های خط فرمان را مشخص می‌کند که با فاصله از هم جدا شده‌اند. برای شرح گزینه‌های موجود، به Overview of Java Options مراجعه کنید.
نام کلاسی را که باید اجرا شود مشخص می‌کند. ورودی‌های خط فرمان پس از classname، آرگومان‌های متد اصلی (main) هستند.
-jar jarfile
برنامه‌ای را که درون یک فایل JAR بسته‌بندی شده است اجرا می‌کند. آرگومان jarfile نام یک فایل JAR به همراه مانیفستی است که شامل خطی به شکل Main-Class:classname است و کلاسی را که دارای متد public static void main(String[] args) به عنوان نقطه شروع برنامه شماست، تعریف می‌کند. هنگام استفاده از -jar، فایل JAR مشخص‌شده منبع تمامی کلاس‌های کاربر است و سایر تنظیمات مسیر کلاس (class path) نادیده گرفته می‌شوند. اگر از فایل‌های JAR استفاده می‌کنید، jar را ببینید.
-m یا --module module[/mainclass]
کلاس اصلی را در ماژول اجرا می‌کند؛ در صورت تعیین شدن، کلاس مشخص‌شده توسط mainclass و در صورت مشخص نشدن، مقدار درون module را اجرا می‌کند. به بیان دیگر، mainclass می‌تواند در صورت عدم تعیین در ماژول، یا برای بازنویسی مقدار مشخص‌شده به کار رود.

به Standard Options for Java مراجعه کنید.

تنها برای اجرای یک برنامه تک‌فایلی کد منبع استفاده می‌شود. فایل منبعی را مشخص می‌کند که در هنگام استفاده از حالت فایل منبع (source-file mode) شامل کلاس اصلی است. به Using Source-File Mode to Launch Single-File 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 Single-File Source-Code Programs مراجعه کنید.

نکته: می‌توانید از متغیر محیطیِ راه‌اندازِ JDK_JAVA_OPTIONS برای افزودن محتوای آن به ابتدای خط فرمان واقعی راه‌انداز java استفاده کنید. به Using the JDK_JAVA_OPTIONS Launcher Environment Variable مراجعه کنید.

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

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

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

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

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

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

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

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

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

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

java HelloWorld.java

این مثال نشان می‌دهد که کلاس می‌تواند در یک بستهٔ نام‌دار (named package) باشد و نیازی نیست حتماً در بستهٔ بی‌نام (unnamed package) قرار داشته باشد. این استفاده از حالت فایل منبع به صورت غیررسمی معادل اجرای دو دستور زیر است که در آن‌ها hello.World نام کلاس در بسته است:


javac -d <memory> HelloWorld.java
java -cp <memory> hello.World

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

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

این شامل این گزینه‌هاست: --class-path، --module-path، --add-exports، --add-modules، --limit-modules، --patch-module، --upgrade-module-path و هرگونه اشکال مختلف این گزینه‌ها. همچنین شامل گزینهٔ جدید --enable-preview است که در JEP 12 توضیح داده شده است.

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

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

•
هرگونه گزینهٔ خط فرمان که با محیط کامپایل مرتبط باشد در نظر گرفته می‌شود.
•
هیچ فایل منبع دیگری جستجو و کامپایل نمی‌شود، درست مانند اینکه مسیر منبع (source path) روی مقداری خالی تنظیم شده باشد.
•
پردازش حاشیه‌نویسی‌ها (Annotation processing) غیرفعال است، درست مانند اینکه -proc:none اعمال شده باشد.
•
اگر نسخه‌ای از طریق گزینهٔ --source مشخص شده باشد، این مقدار به عنوان آرگومان برای یک گزینهٔ ضمنی --release در کامپایل استفاده می‌شود. این کار هم نسخهٔ منبع پذیرفته‌شده توسط کامپایلر و هم API سامانه‌ای را که ممکن است توسط کد درون فایل منبع استفاده شود، تنظیم می‌کند.
•
فایل منبع در زمینهٔ یک ماژول بی‌نام کامپایل می‌شود.
•
فایل منبع باید شامل یک یا چند کلاس سطح بالا (top-level) باشد که نخستین کلاس به عنوان کلاس قابل اجرا در نظر گرفته می‌شود.
•
کامپایلر محدودیت اختیاری تعریف‌شده در انتهای JLS 7.6 را اعمال نمی‌کند؛ این محدودیت که نوع موجود در یک بستهٔ نام‌دار باید در فایلی قرار داشته باشد که نام آن از نام همان نوع همراه با پسوند .java تشکیل شده باشد.
•
اگر فایل منبع حاوی خطا باشد، پیام‌های خطای مناسب در جریان خطای استاندارد نوشته می‌شوند و اجراکننده با یک کد خروج غیرصفر خارج می‌شود.

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

•
کلاس قابل اجرا، نخستین کلاس سطح بالایی است که در فایل منبع یافت می‌شود. این کلاس باید حاوی اعلان متد استاندارد public static void main(String[]) باشد.
•
کلاس‌های کامپایل‌شده توسط یک بارگذار کلاس سفارشی بارگذاری می‌شوند که وظیفه را به بارگذار کلاس برنامه (application class loader) واگذار می‌کند. این بدان معناست که کلاس‌های حاضر در مسیر کلاس برنامه (application class path) نمی‌توانند به هیچ کلاسی که در فایل منبع اعلان شده است ارجاع دهند.
•
کلاس‌های کامپایل‌شده در زمینهٔ یک ماژول بی‌نام اجرا می‌شوند، گویی که --add-modules=ALL-DEFAULT اعمال شده است. این مورد علاوه بر هر گزینهٔ --add-module دیگری است که ممکن است در خط فرمان تعیین شده باشد.
•
هرگونه آرگومانی که در خط فرمان پس از نام فایل ظاهر شود، به شیوهٔ معمول به متد استاندارد main فرستاده می‌شود.
•
اگر کلاسی در مسیر کلاس برنامه وجود داشته باشد که نام آن هم‌نام با کلاسِ در حال اجرا باشد، یک خطا رخ خواهد داد.

برای جزئیات کامل، JEP 330: Launch Single-File Source-Code Programs به نشانی [https://openjdk.org/jeps/330] را ببینید..SH "استفاده از متغیر محیطی راه‌انداز JDK_JAVA_OPTIONS (USING THE JDK_JAVA_OPTIONS LAUNCHER ENVIRONMENT VARIABLE)"

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

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

مثال:


$ 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، تنظیم مسیر کلاس (class path)، فعال‌سازی خروجی پرگو (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 تا 1 استفاده کنید. برای مثال، مقدار 0.25 را برای ۲۵٪ تعیین کنید.

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

•
گزینه‌های منسوخ‌شده جاوا (Deprecated Java Options): پذیرفته شده و طبق آن‌ها عمل می‌شود — هنگام استفاده از آن‌ها یک هشدار صادر می‌شود.
•
گزینه‌های متروک جاوا (Obsolete Java Options): پذیرفته می‌شوند اما نادیده گرفته می‌شوند — هنگام استفاده از آن‌ها یک هشدار صادر می‌شود.
•
گزینه‌های حذف‌شده جاوا (Removed Java Options): حذف شده‌اند — استفاده از آن‌ها منجر به خطا می‌شود..SH "گزینه‌های استاندارد جاوا (STANDARD OPTIONS FOR JAVA)"

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

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

-agentlib:libname[=options]
کتابخانه محلی عامل (native agent) مشخص‌شده را بارگذاری می‌کند. پس از نام کتابخانه، می‌توان از فهرستی از گزینه‌های اختصاصی کتابخانه که با کاما از هم جدا شده‌اند استفاده کرد. اگر گزینه -agentlib:foo مشخص شده باشد، JVM تلاش می‌کند کتابخانه‌ای با نام foo را با استفاده از قواعد نام‌گذاری و مکان‌های خاص هر پلتفرم بارگذاری کند:
•
لینوکس و سایر پلتفرم‌های شبه‌پازیکس (POSIX-like): ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای به نام libfoo.so را در مکان مشخص‌شده توسط متغیر سیستمی LD_LIBRARY_PATH بارگذاری کند.
•
مک‌اواس (macOS): ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای به نام libfoo.dylib را در مکان مشخص‌شده توسط متغیر سیستمی DYLD_LIBRARY_PATH بارگذاری کند.
•
ویندوز (Windows): ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای به نام foo.dll را در مکان مشخص‌شده توسط متغیر سیستمی PATH بارگذاری کند.

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

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

-agentpath:pathname[=options]
کتابخانه محلی عامل را با استفاده از نام مسیر مطلق مشخص‌شده بارگذاری می‌کند. این گزینه معادل -agentlib است اما از مسیر کامل و نام فایل کتابخانه استفاده می‌کند.
--class-path classpath، -classpath classpath، یا -cp classpath
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را برای جستجوی فایل‌های کلاس مشخص می‌کند.

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

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

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

--disable-@files
می‌تواند در هر جایی از خط فرمان، از جمله درون یک فایل آرگومان استفاده شود تا از بسط بیشتر @filename جلوگیری کند. این گزینه بسط فایل‌های آرگومان @ را پس از این گزینه متوقف می‌کند.
--enable-preview
به کلاس‌ها اجازه می‌دهد به ویژگی‌های پیش‌نمایش [https://docs.oracle.com/en/java/javase/12/language/index.html#JSLAN-GUID-5A82FE0E-0CA4-4F1F-B075-564874FE2823] این نسخه وابسته باشند.
--finalization=value
کنترل می‌کند که آیا JVM نهایی‌سازی (finalization) اشیاء را انجام دهد یا خیر. مقادیر معتبر عبارتند از "enabled" و "disabled". نهایی‌سازی به‌طور پیش‌فرض فعال است، بنابراین مقدار "enabled" کاری انجام نمی‌دهد. مقدار "disabled" نهایی‌سازی را غیرفعال می‌کند، به‌طوری که هیچ نهایی‌سازی فراخوانی نمی‌شود.
--module-path modulepath... یا -p modulepath
مکان یافتن ماژول‌های برنامه را با فهرستی از عناصر مسیر مشخص می‌کند. عناصر مسیر ماژول می‌توانند یک مسیر فایل به یک ماژول یا دایرکتوری حاوی ماژول‌ها باشند. هر ماژول یا یک JAR ماژولار است یا یک دایرکتوری ماژول بازشده (exploded-module).

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

--upgrade-module-path modulepath...
مکان یافتن ماژول‌های جایگزین برای ماژول‌های قابل ارتقا در تصویر زمان اجرا را با فهرستی از عناصر مسیر مشخص می‌کند. عناصر مسیر ماژول می‌توانند یک مسیر فایل به یک ماژول یا دایرکتوری حاوی ماژول‌ها باشند. هر ماژول یا یک JAR ماژولار است یا یک دایرکتوری ماژول بازشده (exploded-module).

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

--add-modules module[,module...]
ماژول‌های ریشه را علاوه بر ماژول اولیه برای حل وابستگی مشخص می‌کند. module همچنین می‌تواند ALL-DEFAULT، ALL-SYSTEM و ALL-MODULE-PATH باشد.
--list-modules
ماژول‌های قابل مشاهده را فهرست کرده و سپس خارج می‌شود.
-d module_name یا --describe-module module_name
یک ماژول مشخص‌شده را توصیف کرده و سپس خارج می‌شود.
--dry-run
ماشین مجازی (VM) را ایجاد می‌کند اما متد اصلی (main) را اجرا نمی‌کند. این گزینه --dry-run ممکن است برای اعتبارسنجی گزینه‌های خط فرمان مانند پیکربندی سیستم ماژول مفید باشد.
--validate-modules
تمام ماژول‌ها را اعتبارسنجی کرده و خارج می‌شود. این گزینه برای یافتن تداخل‌ها و خطاهای دیگر با ماژول‌های موجود در مسیر ماژول مفید است.
-Dproperty=value
مقدار یک ویژگی سیستمی را تنظیم می‌کند. متغیر property رشته‌ای بدون فاصله است که نام ویژگی را نشان می‌دهد. متغیر value رشته‌ای است که مقدار ویژگی را نشان می‌دهد. اگر value رشته‌ای حاوی فاصله است، آن را داخل علامت نقل قول قرار دهید (برای مثال -Dfoo="foo bar";).
-disableassertions[:[packagename]...|:classname] یا -da[:[packagename]...|:classname]
ادعاها (assertions) را غیرفعال می‌کند. به‌طور پیش‌فرض، ادعاها در تمام بسته‌ها و کلاس‌ها غیرفعال هستند. بدون آرگومان، -disableassertions (-da) ادعاها را در تمام بسته‌ها و کلاس‌ها غیرفعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، این سوییچ ادعاها را در بسته مشخص‌شده و هر زیربسته‌ای از آن غیرفعال می‌کند. اگر آرگومان صرفاً ... باشد، سوییچ ادعاها را در بسته بدون نام در دایرکتوری کاری جاری غیرفعال می‌کند. با آرگومان classname، این سوییچ ادعاها را در کلاس مشخص‌شده غیرفعال می‌کند.

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

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

-disablesystemassertions یا -dsa
ادعاها را در تمام کلاس‌های سیستمی غیرفعال می‌کند.
-enableassertions[:[packagename]...|:classname] یا -ea[:[packagename]...|:classname]
ادعاها را فعال می‌کند. به‌طور پیش‌فرض، ادعاها در تمام بسته‌ها و کلاس‌ها غیرفعال هستند. بدون آرگومان، -enableassertions (-ea) ادعاها را در تمام بسته‌ها و کلاس‌ها فعال می‌کند. با آرگومان packagename که به ... ختم می‌شود، این سوییچ ادعاها را در بسته مشخص‌شده و هر زیربسته‌ای از آن فعال می‌کند. اگر آرگومان صرفاً ... باشد، سوییچ ادعاها را در بسته بدون نام در دایرکتوری کاری جاری فعال می‌کند. با آرگومان classname، این سوییچ ادعاها را در کلاس مشخص‌شده فعال می‌کند. گزینهٔ -enableassertions (-ea) بر تمام بارگذارهای کلاس (class loaders) و کلاس‌های سیستمی (که فاقد بارگذار کلاس هستند) اعمال می‌شود. یک استثنا برای این قاعده وجود دارد: اگر این گزینه بدون هیچ آرگومانی ارائه شود، بر کلاس‌های سیستمی اعمال نخواهد شد. این امر فعال‌سازی ادعاها (assertions) را در تمام کلاس‌ها به‌جز کلاس‌های سیستمی آسان می‌کند. گزینهٔ -enablesystemassertions سوییچ جداگانه‌ای برای فعال‌سازی ادعاها در تمام کلاس‌های سیستمی فراهم می‌کند. برای غیرفعال‌سازی صریح ادعاها در بسته‌ها یا کلاس‌های مشخص، از گزینهٔ -disableassertions (-da) استفاده کنید. اگر یک دستور حاوی چندین نمونه از این سوییچ‌ها باشد، آن‌ها به همان ترتیبِ مشخص‌شده، پیش از بارگذاری هر کلاسی پردازش می‌شوند. برای نمونه، جهت اجرای برنامهٔ MyClass در حالی که ادعاها تنها در بستهٔ com.wombat.fruitbat (و هریک از زیربسته‌های آن) فعال و در کلاس com.wombat.fruitbat.Brickbat غیرفعال باشند، از دستور زیر استفاده کنید:

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

-enablesystemassertions یا -esa
ادعاها (assertions) را در تمام کلاس‌های سیستمی فعال می‌کند.
-help، -h یا -?
پیام راهنما را در جریان خطا (error stream) چاپ می‌کند.
--help
پیام راهنما را در جریان خروجی (output stream) چاپ می‌کند.
-javaagent:jarpath[=options]
عامل (agent) مشخص‌شدهٔ زبان برنامه‌نویسی جاوا را بارگذاری می‌کند. بخش java.lang.instrument را ببینید.
--show-version
نسخهٔ محصول را در جریان خروجی چاپ کرده و به اجرا ادامه می‌دهد.
-showversion
نسخهٔ محصول را در جریان خطا چاپ کرده و به اجرا ادامه می‌دهد.
--show-module-resolution
خروجی تفکیک ماژول‌ها (module resolution) را هنگام راه‌اندازی نمایش می‌دهد.
-splash:imagepath
صفحهٔ آغازین (splash screen) را با تصویر مشخص‌شده توسط imagepath نمایش می‌دهد. تصاویر مقیاس‌بندی‌شدهٔ HiDPI به‌طور خودکار پشتیبانی شده و در صورت دردسترس بودن مورد استفاده قرار می‌گیرند. نام فایل تصویرِ بدون مقیاس، مانند image.ext، همیشه باید به‌عنوان آرگومان به گزینهٔ -splash داده شود. مناسب‌ترین تصویر مقیاس‌بندی‌شدهٔ ارائه‌شده به‌طور خودکار انتخاب می‌شود.

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

-splash:images/splash.gif

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

-verbose:class
اطلاعات مربوط به هر کلاس بارگذاری‌شده را نمایش می‌دهد.
-verbose:gc
اطلاعات مربوط به هر رویداد بازیافت حافظه (GC) را نمایش می‌دهد.
-verbose:jni
اطلاعات مربوط به استفاده از متدهای بومی و سایر فعالیت‌های رابط بومی جاوا (JNI) را نمایش می‌دهد.
-verbose:module
اطلاعات مربوط به ماژول‌های در حال استفاده را نمایش می‌دهد.
--version
نسخهٔ محصول را در جریان خروجی چاپ کرده و خارج می‌شود.
-version
نسخهٔ محصول را در جریان خطا چاپ کرده و خارج می‌شود.
-X
راهنمای گزینه‌های اضافی را در جریان خطا چاپ می‌کند.
--help-extra
راهنمای گزینه‌های اضافی را در جریان خروجی چاپ می‌کند.
@argfile
یک یا چند فایل آرگومان را که با پیشوند @ مشخص می‌شوند برای استفاده توسط دستور java تعیین می‌کند. به‌دلیل فایل‌های .jar متعددی که در classpath مورد نیاز است، طولانی شدن خط فرمان java امری نامعمول نیست. گزینهٔ @argfile با فراهم آوردن امکان بسط محتوای فایل‌های آرگومان پس از بسط پوسته، اما پیش از پردازش آرگومان‌ها توسط راه‌انداز، بر محدودیت‌های طول خط فرمان غلبه می‌کند. محتویات فایل‌های آرگومان بسط داده می‌شوند؛ در غیر این صورت تا پیش از رسیدن به گزینهٔ --disable-@files، عیناً روی خط فرمان مشخص می‌شدند.

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

java @argfile

برای توضیحات و مثال‌هایی از کاربرد @-argfileها، به بخش java Command-Line Argument Files مراجعه کنید.

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

-Xbatch
کامپایل پس‌زمینه را غیرفعال می‌کند. به‌طور پیش‌فرض، JVM متد را به‌عنوان یک وظیفهٔ پس‌زمینه کامپایل کرده و تا زمان پایان کامپایل پس‌زمینه، متد را در حالت تفسیری (interpreter mode) اجرا می‌کند. پرچم -Xbatch کامپایل پس‌زمینه را غیرفعال می‌سازد تا کامپایل همهٔ متدها به‌عنوان یک وظیفهٔ پیش‌زمینه تا زمان تکمیل ادامه یابد. این گزینه معادل -XX:-BackgroundCompilation است.
-Xbootclasspath/a:directories|zip|JAR-files
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را برای الحاق به انتهای مسیر کلاس راه‌انداز (bootstrap class path) پیش‌فرض مشخص می‌کند.

در Windows، نقطه‌ویرگول (;) موارد موجود در این فهرست را جدا می‌کند؛ در سایر پلتفرم‌ها این کار با دونقطه (:) انجام می‌شود.

-Xcheck:jni
بررسی‌های تکمیلی را برای توابع رابط بومی جاوا (JNI) انجام می‌دهد.

بررسی‌های زیر نشان‌دهندهٔ مشکلات اساسی در کد بومی در نظر گرفته می‌شوند و JVM در چنین مواردی با یک خطای جبران‌ناپذیر متوقف می‌شود:

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

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

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

هنگام استفاده از این گزینه، انتظار افت کارایی را داشته باشید. -Xcomp حالت آزمایشی برای محک زدن کامپایلرهای JIT. این گزینه نباید در محیط‌های عملیاتی استفاده شود.

-Xdebug
کاری انجام نمی‌دهد. تنها جهت سازگاری با نسخه‌های پیشین ارائه شده است.
-Xdiag
پیام‌های تشخیصی اضافی را نمایش می‌دهد.
-Xint
برنامه را فقط در حالت مفسری اجرا می‌کند. کامپایل به کد بومی غیرفعال شده و تمام بایت‌کدها توسط مفسر اجرا می‌شوند. مزایای کارایی ارائه‌شده توسط کامپایلر درجا (JIT) در این حالت وجود ندارند.
-Xinternalversion
اطلاعات دقیق‌تری از نسخهٔ JVM را نسبت به گزینهٔ -version نمایش داده و سپس خارج می‌شود.
-Xlog:option
پیکربندی یا فعال‌سازی ثبت وقایع (لاگ‌گیری) با چارچوب یکپارچهٔ لاگ‌گیری ماشین مجازی جاوا (JVM). بخش Enable Logging with the JVM Unified Logging Framework را ببینید.
-Xmixed
همهٔ بایت‌کدها را توسط مفسر اجرا می‌کند، به‌جز متدهای پرکاربرد (hot methods) که به کد بومی کامپایل می‌شوند. به‌طور پیش‌فرض فعال است. برای غیرفعال کردن از -Xint استفاده کنید.
-Xmn size
اندازهٔ اولیه و بیشینه (به بایت) هیپ را برای نسل جوان (nursery) در زباله‌روب‌های نسلی تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. ناحیهٔ نسل جوان در هیپ برای اشیاء جدید استفاده می‌شود. عملیات زباله‌روبی (GC) در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد. اگر اندازهٔ نسل جوان بیش از حد کوچک باشد، زباله‌روبی‌های جزئی (minor) متعددی انجام خواهد شد. اگر اندازه بیش از حد بزرگ باشد، تنها زباله‌روبی‌های کامل انجام می‌شوند که تکمیل آن‌ها می‌تواند زمان زیادی ببرد. توصیه می‌شود که اندازهٔ نسل جوان را برای زباله‌روب G1 تعیین نکنید، و برای سایر زباله‌روب‌ها اندازهٔ نسل جوان را بیشتر از ۲۵٪ و کمتر از ۵۰٪ کل اندازهٔ هیپ نگه دارید. مثال‌های زیر نحوهٔ تنظیم اندازهٔ اولیه و بیشینهٔ نسل جوان را روی 256 MB با استفاده از واحدهای مختلف نشان می‌دهند:

-Xmn256m
-Xmn262144k
-Xmn268435456

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

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

-Xms6291456
-Xms6144k
-Xms6m

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

توجه داشته باشید که از گزینهٔ -XX:InitialHeapSize نیز می‌توان برای تنظیم اندازهٔ اولیهٔ هیپ استفاده کرد. چنانچه این گزینه پس از -Xms در خط فرمان بیاید، اندازهٔ اولیهٔ هیپ روی مقدار مشخص‌شده با -XX:InitialHeapSize تنظیم می‌شود.

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

-Xmx83886080
-Xmx81920k
-Xmx80m

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

-Xnoclassgc
زباله‌روبی (GC) کلاس‌ها را غیرفعال می‌کند. این کار می‌تواند مقداری از زمان GC را ذخیره کرده و وقفه‌ها در طول اجرای برنامه را کوتاه‌تر کند. هنگامی که هنگام راه‌اندازی گزینهٔ -Xnoclassgc را مشخص می‌کنید، اشیاء مربوط به کلاس‌ها در طول زباله‌روبی دست‌نخورده باقی می‌مانند و همواره زنده تلقی می‌شوند. این امر می‌تواند باعث اشغال دائمی حافظهٔ بیشتری شود که در صورت عدم دقت در مصرف، خطای کمبود حافظه (out-of-memory) ایجاد خواهد کرد.
-Xrs
استفاده از سیگنال‌های سیستم‌عامل توسط JVM را کاهش می‌دهد. قلاب‌های خروج (shutdown hooks) با اجرای کدهای پاک‌سازی کاربر (نظیر بستن اتصالات پایگاه داده) در هنگام خروج، امکان خاموش شدن منظم برنامهٔ جاوا را فراهم می‌سازند، حتی اگر JVM به‌طور ناگهانی خاتمه یابد.
•
سیستم‌های غیر ویندوزی (Non-Windows):
•
ماشین JVM برای پیاده‌سازی قلاب‌های خروج در هنگام خاتمه‌های نامنتظره، سیگنال‌ها را دریافت می‌کند. ماشین JVM از SIGHUP، SIGINT و SIGTERM برای آغاز اجرای قلاب‌های خروج استفاده می‌کند.
•
برنامه‌هایی که JVM را درون خود تعبیه می‌کنند، معمولاً نیاز به دریافت سیگنال‌هایی چون SIGINT یا SIGTERM دارند که می‌تواند منجر به تداخل با گرداننده‌های سیگنال JVM شود. گزینهٔ -Xrs برای رسیدگی به این مسئله تدارک دیده شده است. هنگامی که -Xrs استفاده می‌شود، ماسک سیگنال‌ها برای SIGINT، SIGTERM، SIGHUP و SIGQUIT توسط JVM تغییر داده نمی‌شود و هیچ گرداننده‌ای برای این سیگنال‌ها نصب نخواهد شد.
•
ویندوز (Windows):
•
ماشین JVM رویدادهای کنترلی کنسول را برای پیاده‌سازی قلاب‌های خروج در شرایط خاتمهٔ نامنتظره زیر نظر می‌گیرد. به‌ویژه، JVM یک گردانندهٔ کنترل کنسول ثبت می‌کند که پردازش قلاب خروج را آغاز کرده و برای رویدادهای CTRL_C_EVENT، CTRL_CLOSE_EVENT، CTRL_LOGOFF_EVENT و CTRL_SHUTDOWN_EVENT مقدار TRUE بازمی‌گرداند.
•
ماشین JVM سازوکار مشابهی را برای پیاده‌سازی قابلیت تخلیهٔ پشتهٔ ریسه‌ها (thread dumps) جهت مقاصد اشکال‌زدایی به‌کار می‌برد. ماشین JVM از CTRL_BREAK_EVENT برای تخلیهٔ پشتهٔ ریسه‌ها استفاده می‌کند.
•
اگر JVM به‌صورت یک سرویس اجرا شود (به‌عنوان نمونه، به‌عنوان یک موتور سرولت برای یک وب‌سرور)، ممکن است CTRL_LOGOFF_EVENT را دریافت کند اما نباید فرایند خاموش شدن را آغاز نماید، چرا که سیستم‌عامل در عمل فرایند را خاتمه نمی‌دهد. جهت پیشگیری از چنین تداخلات احتمالی، می‌توان از گزینهٔ -Xrs استفاده کرد. زمانی که گزینهٔ -Xrs به‌کار رود، JVM هیچ گردانندهٔ کنترل کنسولی نصب نمی‌کند که این بدان معناست رویدادهای CTRL_C_EVENT، CTRL_CLOSE_EVENT، CTRL_LOGOFF_EVENT یا CTRL_SHUTDOWN_EVENT زیر نظر گرفته یا پردازش نمی‌شوند.

مشخص کردن گزینهٔ -Xrs دو پیامد در پی دارد:

•
سیستم‌های غیر ویندوزی: تخلیهٔ پشتهٔ ریسه‌ها با سیگنال SIGQUIT در دسترس نخواهد بود.
•
ویندوز: تخلیهٔ پشتهٔ ریسه‌ها با کلیدهای میانبر Ctrl + Break در دسترس نخواهد بود.

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

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

آرگومان‌های ممکن برای mode در این گزینه شامل موارد زیر است:.TP auto در صورت امکان از داده‌های کلاس مشترک استفاده می‌کند (پیش‌فرض).

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

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

off
تلاشی برای استفاده از داده‌های کلاس مشترک نمی‌کند.
-XshowSettings
تمام تنظیمات را نمایش داده و سپس ادامه می‌دهد.
-XshowSettings:category
تنظیمات را نمایش داده و ادامه می‌دهد. آرگومان‌های ممکن category برای این گزینه شامل موارد زیر هستند:
all
تمام دسته‌بندی‌های تنظیمات را نمایش می‌دهد. این مقدار پیش‌فرض است.
locale
تنظیمات مربوط به locale را نمایش می‌دهد.
properties
تنظیمات مربوط به ویژگی‌های سیستم (system properties) را نمایش می‌دهد.
vm
تنظیمات JVM را نمایش می‌دهد.
system
فقط لینوکس: پیکربندی سیستم میزبان یا کانتینر را نمایش داده و ادامه می‌دهد.
-Xss size
اندازه پشته ریسه (thread stack size) را (به بایت) تنظیم می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مشخص کردن مگابایت، یا g یا G را برای مشخص کردن گیگابایت اضافه کنید. اندازه واقعی ممکن است بر اساس نیاز سیستم‌عامل به مضربی از اندازه صفحه سیستم (system page size) گرد شود. مقدار پیش‌فرض به سیستم‌عامل و پلتفرم بستگی دارد. به عنوان مثال:
•
Linux/x64: 1024 KB
•
Linux/Aarch64: 2048 KB
•
macOS/x64: 1024 KB
•
macOS/Aarch64: 2048 KB
•
Windows: مقدار پیش‌فرض به حافظه مجازی بستگی دارد

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


-Xss1m
-Xss1024k
-Xss1048576

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

--add-reads module=target-module(,target-module)*
ماژول module را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، target-module را بخواند. مقدار target-module می‌تواند all unnamed باشد تا تمام ماژول‌های بدون نام را بخواند.
--add-exports module/package=target-module(,target-module)*
ماژول module را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، package را به target-module صادر کند. مقدار target-module می‌تواند all unnamed باشد تا به تمام ماژول‌های بدون نام صادر شود.
--add-opens module/package=target-module(,target-module)*
ماژول module را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، package را برای target-module باز کند.
--limit-modules module[,module...]
محدوده جهان ماژول‌های قابل مشاهده را تعیین می‌کند.
--patch-module module=file(;file)*
یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها جایگزین یا تقویت می‌کند.
--source version
نسخه سورس (source) را در حالت فایل سورس (source-file mode) تنظیم می‌کند.

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

-XstartOnFirstThread
متد main() را در اولین ریسه (AppKit) اجرا می‌کند.
-Xdock:name=application_name
نام پیش‌فرض برنامه که در dock نمایش داده می‌شود را بازنویسی می‌کند.
-Xdock:icon=path_to_icon_file
آیکون پیش‌فرض نمایش داده‌شده در dock را بازنویسی می‌کند.

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

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

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

-XX:+UnlockExperimentalVMOptions
گزینه‌هایی که ویژگی‌های آزمایشی را در JVM ارائه می‌دهند قفل‌گشایی می‌کند. به طور پیش‌فرض، این گزینه غیرفعال است و ویژگی‌های آزمایشی در دسترس نیستند..SH "گزینه‌های پیشرفته زمان اجرا برای جاوا (ADVANCED RUNTIME OPTIONS FOR JAVA)"

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

-XX:ActiveProcessorCount=x
تعداد CPUهایی را بازنویسی می‌کند که VM برای محاسبه اندازه استخرهای ریسه (thread pools) جهت عملیات‌های گوناگون مانند Garbage Collection و ForkJoinPool استفاده خواهد کرد.

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

-XX:AllocateHeapAt=path
مسیری به سیستم فایل را دریافت کرده و از نگاشت حافظه برای تخصیص هیپ اشیاء (object heap) روی دستگاه حافظه استفاده می‌کند. استفاده از این گزینه HotSpot VM را قادر می‌سازد تا هیپ اشیاء جاوا را روی یک دستگاه حافظه جایگزین که توسط کاربر مشخص شده است، مانند یک NV-DIMM، تخصیص دهد.

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

برخی از سیستم‌عامل‌ها حافظه غیر-DRAM را از طریق سیستم فایل ارائه می‌دهند. فایل‌های نگاشت‌شده در حافظه (memory-mapped) در این سیستم‌فایل‌ها حافظه پنهان صفحه (page cache) را دور می‌زنند و نگاشت مستقیمی از حافظه مجازی به حافظه فیزیکی روی دستگاه فراهم می‌کنند. پرچم‌های موجود مربوط به هیپ (مانند -Xmx و -Xms) و پرچم‌های مربوط به garbage collection همچنان مانند گذشته کار می‌کنند.

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

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

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

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

-XX:ErrorFile=filename
مسیر و نام فایلی را مشخص می‌کند که داده‌های خطا در صورت بروز خطای جبران‌ناپذیر در آن نوشته می‌شوند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری فعلی ایجاد می‌شود و با نام hs_err_pidpid.log ذخیره می‌گردد که در آن pid شناسه فرایندی است که با خطا مواجه شده است.

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

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

•
غیر ویندوز (Non-Windows): مثال زیر نحوه تنظیم لاگ خطا روی /var/log/java/java_error.log را نشان می‌دهد:

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

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

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

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

•
غیر ویندوز (Non-Windows): دایرکتوری موقت /tmp است.
•
ویندوز (Windows): دایرکتوری موقت توسط مقدار متغیر محیطی TMP مشخص می‌شود؛ اگر این متغیر محیطی تعریف نشده باشد، از مقدار متغیر محیطی TEMP استفاده می‌شود.
-XX:+ExtensiveErrorReports
گزارش‌دهی اطلاعات خطای گسترده‌تر را در ErrorFile فعال می‌کند. این گزینه می‌تواند در محیط‌هایی فعال شود که حداکثر اطلاعات مورد نیاز است - حتی اگر لاگ‌های حاصل بسیار حجیم باشند و/یا حاوی اطلاعاتی باشند که حساس تلقی شوند. اطلاعات می‌تواند از نگارشی به نگارش دیگر و در بسترهای مختلف متفاوت باشد. به‌طور پیش‌فرض این گزینه غیرفعال است.
-XX:FlightRecorderOptions=parameter=value (یا) -XX:FlightRecorderOptions:parameter=value
پارامترهایی را تعیین می‌کند که رفتار JFR را کنترل می‌کنند. چندین پارامتر را می‌توان با جدا کردن آنها توسط کاما مشخص کرد.

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

globalbuffersize=size
مقدار کل حافظه اصلی استفاده‌شده برای نگهداری داده‌ها را مشخص می‌کند. مقدار پیش‌فرض بر اساس مقدار مشخص‌شده برای memorysize است. برای تغییر اندازه بافرهای سراسری، پارامتر memorysize را تغییر دهید.
maxchunksize=size
حداکثر اندازه (به بایت) تکه‌داده‌ها در یک ضبط را مشخص می‌کند. برای مشخص کردن اندازه بر حسب مگابایت (MB) حرف m یا M، یا برای گیگابایت (GB) حرف g یا G را پیوست کنید. به‌طور پیش‌فرض، حداکثر اندازه تکه‌داده‌ها روی 12 مگابایت تنظیم شده است. حداقل مقدار مجاز 1 مگابایت است.
memorysize=size
تعیین می‌کند چه مقدار حافظه بافر باید استفاده شود، و پارامترهای globalbuffersize و numglobalbuffers را بر اساس اندازه مشخص‌شده تنظیم می‌کند. برای مشخص کردن اندازه بر حسب مگابایت (MB) حرف m یا M، یا برای گیگابایت (GB) حرف g یا G را پیوست کنید. به‌طور پیش‌فرض، اندازه حافظه روی 10 مگابایت تنظیم شده است.
numglobalbuffers
تعداد بافرهای سراسری استفاده‌شده را مشخص می‌کند. مقدار پیش‌فرض بر اساس اندازه حافظه مشخص‌شده تعیین می‌شود. برای تغییر تعداد بافرهای سراسری، پارامتر memorysize را تغییر دهید.
old-object-queue-size=number-of-objects
حداکثر تعداد اشیاء قدیمی (old objects) برای ردیابی. به‌طور پیش‌فرض، تعداد اشیاء روی ۲۵۶ تنظیم شده است.
preserve-repository={true|false}
مشخص می‌کند که آیا فایل‌های ذخیره‌شده در مخزن دیسک باید پس از خروج JVM نگه داشته شوند یا خیر. اگر false باشد، فایل‌ها حذف می‌شوند. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
repository=path
مخزن (یک دایرکتوری) را برای ذخیره‌سازی موقت دیسک مشخص می‌کند. به‌طور پیش‌فرض، از دایرکتوری موقت سیستم استفاده می‌شود.
retransform={true|false}
مشخص می‌کند که آیا کلاس‌های رویداد باید با استفاده از JVMTI بازدگرگون (retransform) شوند یا خیر. اگر false باشد، آماده‌سازی (instrumentation) هنگام بارگیری کلاس‌های رویداد اضافه می‌شود. به‌طور پیش‌فرض، این پارامتر فعال است.
stackdepth=depth
عمق پشته برای ردگیری پشته (stack trace). به‌طور پیش‌فرض، عمق روی ۶۴ فراخوانی متد تنظیم شده است. حداکثر مقدار ۲۰۴۸ است. مقادیر بزرگ‌تر از ۶۴ می‌توانند سربار قابل توجهی ایجاد کرده و کارایی را کاهش دهند.
threadbuffersize=size
اندازه بافر محلی به‌ازای هر ریسه را (به بایت) مشخص می‌کند. به‌طور پیش‌فرض، اندازه بافر محلی روی ۸ کیلوبایت با حداقل مقدار ۴ کیلوبایت تنظیم شده است. بازنویسی این پارامتر می‌تواند کارایی را کاهش دهد و توصیه نمی‌شود.
-XX:LargePageSizeInBytes=size
حداکثر اندازه صفحه بزرگ (large page size) استفاده‌شده توسط JVM را (به بایت) تنظیم می‌کند. آرگومان size باید اندازه صفحه معتبری باشد که توسط محیط پشتیبانی می‌شود تا تأثیری داشته باشد. برای تعیین کیلوبایت حرف k یا K، برای مگابایت m یا M، یا برای گیگابایت g یا G را پیوست کنید. به‌طور پیش‌فرض، اندازه روی 0 تنظیم شده است؛ به این معنی که JVM از اندازه پیش‌فرض صفحه بزرگ برای محیط به عنوان حداکثر اندازه برای صفحه‌های بزرگ استفاده خواهد کرد. بخش Large Pages را ببینید. مثال زیر نحوه تنظیم اندازه صفحه‌های بزرگ (large pages) روی ۱ گیگابایت (GB) را شرح می‌دهد:

-XX:LargePageSizeInBytes=1g

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

مثال‌های زیر نحوه تعیین اندازه NIO روی ۱۰۲۴ کیلوبایت با واحدهای مختلف را نشان می‌دهند:


-XX:MaxDirectMemorySize=1m
-XX:MaxDirectMemorySize=1024k
-XX:MaxDirectMemorySize=1048576
-XX:-MaxFDLimit
تلاش برای تنظیم حد نرم (soft limit) تعداد توصیف‌کننده‌های فایل باز به حد سخت (hard limit) را غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه در تمام پلتفرم‌ها فعال است، اما در Windows نادیده گرفته می‌شود. تنها زمانی ممکن است به غیرفعال کردن آن نیاز داشته باشید که روی macOS باشید؛ جایی که استفاده از آن سقف ۱۰۲۴۰ را تحمیل می‌کند که از حداکثر واقعی سیستم کمتر است.
-XX:NativeMemoryTracking=mode
حالت ردیابی مصرف حافظه بومی (native memory) ماشین مجازی جاوا (JVM) را مشخص می‌کند. آرگومان‌های ممکن mode برای این گزینه شامل موارد زیر است:
off
دستور می‌دهد که مصرف حافظه بومی JVM ردیابی نشود. اگر گزینه -XX:NativeMemoryTracking را مشخص نکنید، این رفتار پیش‌فرض است.
summary
مصرف حافظه را فقط بر اساس زیرسیستم‌های JVM مانند هیپ (heap) جاوا، کلاس، کد و ریسه (thread) ردیابی می‌کند.
detail
علاوه بر ردیابی مصرف حافظه بر اساس زیرسیستم‌های JVM، مصرف حافظه را به ازای هر CallSite، هر ناحیه حافظه مجازی مجزا و نواحی متعهدشده‌ی (committed) آن ردیابی می‌کند.
-XX:TrimNativeHeapInterval=millis
فاصله زمانی (به میلی‌ثانیه) که در آن JVM هیپ بومی را هرس (trim) می‌کند. مقادیر کمتر، حافظه را مشتاقانه‌تر بازپس‌گیری می‌کنند اما هزینه سربار بالاتری خواهند داشت. مقدار 0 (پیش‌فرض) هرس هیپ بومی را غیرفعال می‌کند. هرس هیپ بومی در یک ریسه (thread) اختصاصی انجام می‌شود.

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

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

به‌طور پیش‌فرض این پرچم تنها در Windows در حالت ۳۲ بیتی روی true و در تمام موارد دیگر روی false تنظیم است.

در صورت استفاده از هر یک از پرچم‌های زیر در خط فرمان، حالت «Client VM emulation» فعال نخواهد شد:


-XX:{+|-}TieredCompilation
-XX:CompilationMode=mode
-XX:TieredStopAtLevel=n
-XX:{+|-}EnableJVMCI
-XX:{+|-}UseJVMCICompiler
-XX:ObjectAlignmentInBytes=alignment
تراز حافظه (memory alignment) اشیاء جاوا را (به بایت) تنظیم می‌کند. به‌طور پیش‌فرض، مقدار روی ۸ بایت تنظیم شده است. مقدار مشخص‌شده باید توانی از ۲ و در محدوده بین ۸ و ۲۵۶ (شامل هر دو) باشد. این گزینه استفاده از اشاره‌گرهای فشرده (compressed pointers) با اندازه‌های بزرگ هیپ جاوا را امکان‌پذیر می‌سازد.

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

4GB * ObjectAlignmentInBytes

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

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

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

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

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

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

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

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

java/lang/Object
hello/Main

کلاس‌هایی که در این فایل متنی مشخص می‌کنید باید شامل کلاس‌هایی باشند که معمولاً توسط برنامه استفاده می‌شوند. آن‌ها می‌توانند شامل هر کلاسی از مسیرهای کلاس (class paths) برنامه، افزونه (extension) یا راه‌انداز (bootstrap) باشند.

بخش Application Class Data Sharing را ببینید.

-XX:+ShowCodeDetailsInExceptionMessages
چاپ پیام‌های بهبودیافته NullPointerException را فعال می‌کند. هنگامی که یک برنامه یک NullPointerException صادر می‌کند، این گزینه JVM را قادر می‌سازد تا دستورالعمل‌های بایت‌کد (bytecode) برنامه را تجزیه و تحلیل کرده و دقیقاً مشخص کند کدام مرجع null است، و منبع را با یک پیام جزئیات مقدار تهی (null-detail message) توصیف کند. پیام جزئیات مقدار تهی توسط NullPointerException.getMessage() محاسبه و بازگردانده می‌شود، و به همراه متد، نام فایل و شماره خط به عنوان پیام استثنا چاپ خواهد شد. به‌طور پیش‌فرض، این گزینه فعال است.
-XX:+ShowMessageBoxOnError
نمایش یک کادر محاوره‌ای را در هنگام مواجهه JVM با یک خطای غیرقابل‌جبران فعال می‌کند. این کار مانع از خروج JVM شده و فرآیند را فعال نگه می‌دارد تا بتوانید یک دیباگر را برای بررسی علت خطا به آن متصل کنید. به‌طور پیش‌فرض، این گزینه غیرفعال است.
-XX:StartFlightRecording=parameter=value
یک ضبط JFR را برای برنامه Java آغاز می‌کند. این گزینه معادل دستور تشخیصی JFR.start است که ضبط را در زمان اجرا آغاز می‌کند. هنگام آغاز یک ضبط JFR می‌توانید مدخل‌های parameter=value زیر را تنظیم کنید:
delay=time
میزان تاخیر بین زمان راه‌اندازی برنامه Java و آغاز ضبط را مشخص می‌کند. پسوند s را برای مشخص کردن زمان به ثانیه، m برای دقیقه، h برای ساعت، یا d برای روز اضافه کنید (برای مثال، مشخص کردن 10m به معنای ۱۰ دقیقه است). به‌طور پیش‌فرض، هیچ تاخیری وجود ندارد و این پارامتر روی 0 تنظیم شده است.
disk={true|false}
مشخص می‌کند که آیا داده‌ها هنگام ضبط روی دیسک نوشته شوند یا خیر. به‌طور پیش‌فرض، این پارامتر فعال است.
dumponexit={true|false}
مشخص می‌کند که آیا ضبط در حال اجرا هنگام خاموش شدن JVM تخلیه (dump) شود یا خیر. اگر فعال باشد و filename وارد نشده باشد، فایل ضبط در دایرکتوری محل اجرای فرآیند ذخیره می‌شود. نام فایل یک نام تولیدشده توسط سیستم است که حاوی شناسه فرآیند (PID)، شناسه ضبط و برچسب زمانی فعلی است، شبیه به hotspot-pid-47496-id-1-2018_01_25_19_10_41.jfr. به‌طور پیش‌فرض، این پارامتر غیرفعال است.
duration=time
مدت زمان ضبط را مشخص می‌کند. پسوند s را برای مشخص کردن زمان به ثانیه، m برای دقیقه، h برای ساعت، یا d برای روز اضافه کنید (برای مثال، مشخص کردن 5h به معنای ۵ ساعت است). به‌طور پیش‌فرض، مدت زمان محدود نیست و این پارامتر روی 0 تنظیم شده است.
filename=path
مسیر و نام فایلی را مشخص می‌کند که با متوقف شدن ضبط، اطلاعات در آن نوشته می‌شود، برای مثال:
•
recording.jfr
•
/home/user/recordings/recording.jfr
•
c:\recordings\recording.jfr

اگر %p و/یا %t در نام فایل مشخص شده باشد، به ترتیب به PID مربوط به JVM و برچسب زمانی فعلی بسط می‌یابد.

name=identifier
هم نام و هم شناسه یک ضبط را مشخص می‌کند.
maxage=time
حداکثر طول عمر داده‌های دیسک را برای نگهداری در ضبط مشخص می‌کند. این پارامتر فقط زمانی معتبر است که پارامتر disk روی true تنظیم شده باشد. پسوند s را برای مشخص کردن زمان به ثانیه، m برای دقیقه، h برای ساعت، یا d برای روز اضافه کنید (برای مثال، مشخص کردن 30s به معنای ۳۰ ثانیه است). به‌طور پیش‌فرض، حداکثر طول عمر محدود نیست و این پارامتر روی 0s تنظیم شده است.
maxsize=size
حداکثر اندازه (به بایت) داده‌های دیسک را برای نگهداری در ضبط مشخص می‌کند. این پارامتر فقط زمانی معتبر است که پارامتر disk روی true تنظیم شده باشد. مقدار نباید کمتر از مقدار پارامتر maxchunksize باشد که با -XX:FlightRecorderOptions تنظیم شده است. پسوند m یا M را برای مشخص کردن اندازه به مگابایت، یا g یا G را برای مشخص کردن اندازه به گیگابایت اضافه کنید. به‌طور پیش‌فرض، حداکثر اندازه داده‌های دیسک محدود نیست و این پارامتر روی 0 تنظیم شده است.
path-to-gc-roots={true|false}
مشخص می‌کند که آیا مسیر به ریشه‌های جمع‌آوری زباله (GC roots) در انتهای ضبط جمع‌آوری شود یا خیر. به‌طور پیش‌فرض، این پارامتر غیرفعال است.

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

settings=path
مسیر و نام فایل تنظیمات رویداد (از نوع JFC) را مشخص می‌کند. به‌طور پیش‌فرض، از فایل default.jfc واقع در JAVA_HOME/lib/jfr استفاده می‌شود. این فایل تنظیمات پیش‌فرض، مجموعه‌ای از پیش‌تعریف‌شده از اطلاعات را با بار اضافی (overhead) کم جمع‌آوری می‌کند، بنابراین کمترین تأثیر را بر عملکرد دارد و می‌تواند برای ضبط‌هایی که به‌طور مداوم اجرا می‌شوند استفاده شود.

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

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

option=value
مقدار گزینه‌ای را که باید تغییر کند مشخص می‌کند. برای فهرست کردن گزینه‌های موجود، از ابزار JAVA_HOME/bin/jfr استفاده کنید.
event-setting=value
مقدار تنظیم رویدادی را که باید تغییر کند مشخص می‌کند. از قالب روبرو استفاده کنید: <event-name>#<setting-name>=<value>. برای افزودن یک تنظیم رویداد جدید، نام رویداد را با '+' پیشوندگذاری کنید.

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

-XX:ThreadStackSize=size
اندازه پشته ریسه (thread stack size) در Java را (به کیلوبایت) تنظیم می‌کند. استفاده از یک پسوند مقیاس‌بندی، مانند k، منجر به مقیاس‌بندی مقدار کیلوبایت می‌شود، به‌طوری که -XX:ThreadStackSize=1k اندازه پشته ریسه Java را روی 1024*1024 بایت یا ۱ مگابایت تنظیم می‌کند. مقدار پیش‌فرض به بستر بستگی دارد. به عنوان مثال:
•
Linux/x64: 1024 KB
•
Linux/Aarch64: 2048 KB
•
macOS/x64: 1024 KB
•
macOS/Aarch64: 2048 KB
•
Windows: مقدار پیش‌فرض به حافظه مجازی بستگی دارد

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


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

این گزینه مشابه -Xss است.
-XX:-UseCompressedOops
استفاده از اشاره‌گرهای فشرده (compressed pointers) را غیرفعال می‌کند.
به‌طور پیش‌فرض، این گزینه فعال است و از اشاره‌گرهای فشرده استفاده می‌شود.
این امر به‌طور خودکار حداکثر اندازه حافظه heap جاوا را که به‌صورت ارگونومیک تعیین شده، به حداکثر مقدار حافظه‌ای که می‌تواند توسط اشاره‌گرهای فشرده پوشش داده شود محدود می‌کند.
به‌طور پیش‌فرض این محدوده ۳۲ گیگابایت است.
با فعال بودن oops فشرده، ارجاعات به اشیاء به‌جای اشاره‌گرهای ۶۴ بیتی، به‌صورت آفست‌های ۳۲ بیتی نمایش داده می‌شوند که معمولاً هنگام اجرای برنامه با اندازه‌های heap جاوا کوچکتر از محدوده اشاره‌گر oops فشرده، کارایی را افزایش می‌دهد.
این گزینه فقط برای JVMهای ۶۴ بیتی کار می‌کند.
استفاده از اشاره‌گرهای فشرده با اندازه‌های heap جاوا بزرگ‌تر از ۳۲ گیگابایت نیز امکان‌پذیر است.
گزینه -XX:ObjectAlignmentInBytes را ببینید.
-XX:-UseContainerSupport
فقط لینوکس: اکنون VM پشتیبانی از تشخیص خودکار کانتینر را فراهم می‌کند که به VM اجازه می‌دهد مقدار حافظه و تعداد پردازنده‌های در دسترس یک فرایند جاوا را که در کانتینرهای docker اجرا می‌شود، تعیین کند.
از این اطلاعات برای تخصیص منابع سیستم استفاده می‌شود.
مقدار پیش‌فرض برای این پرچم true است و پشتیبانی از کانتینر به‌طور پیش‌فرض فعال است.
می‌توان آن را با -XX:-UseContainerSupport غیرفعال کرد.
قابلیت Unified Logging برای کمک به عیب‌یابی مسائل مربوط به این پشتیبانی در دسترس است.
برای ثبت حداکثری گزارش‌های مربوط به اطلاعات کانتینر از -Xlog:os+container=trace استفاده کنید.
برای توضیحات مربوط به نحوه استفاده از Unified Logging، بخش Enable Logging with the JVM Unified Logging Framework را ببینید.
-XX:+UseHugeTLBFS
فقط لینوکس: این گزینه معادل مشخص کردن -XX:+UseLargePages است.
این گزینه به‌طور پیش‌فرض غیرفعال است.
این گزینه تمام صفحه‌های بزرگ (large pages) را از پیش و در زمان رزرو حافظه تخصیص می‌دهد؛ در نتیجه JVM نمی‌تواند نواحی حافظه صفحه‌های بزرگ را به‌طور پویا بزرگ یا کوچک کند؛ اگر خواهان چنین رفتاری هستید، -XX:UseTransparentHugePages را ببینید.
بخش Large Pages را ببینید.
-XX:+UseLargePages
استفاده از حافظه صفحه بزرگ (large page memory) را فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و از حافظه صفحه بزرگ استفاده نمی‌شود.
بخش Large Pages را ببینید.
-XX:+UseTransparentHugePages
فقط لینوکس: استفاده از صفحه‌های بزرگی را که می‌توانند به‌طور پویا بزرگ یا کوچک شوند فعال می‌کند.
این گزینه به‌طور پیش‌فرض غیرفعال است.
ممکن است با صفحه‌های بزرگ شفاف (transparent huge pages) با افت کارایی مواجه شوید، زیرا سیستم‌عامل برای ایجاد صفحه‌های بزرگ، صفحه‌های دیگر را جابه‌جا می‌کند؛ این گزینه برای آزمایش و ارزیابی در دسترس قرار گرفته است.
-XX:+AllowUserSignalHandlers
سیستم‌های غیر ویندوز: نصب گرداننده‌های سیگنال (signal handlers) توسط برنامه را فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و برنامه اجازه نصب گرداننده‌های سیگنال را ندارد.
-XX:VMOptionsFile=filename
به کاربر اجازه می‌دهد گزینه‌های VM را در یک فایل مشخص کند؛ برای مثال:
java -XX:VMOptionsFile=/var/my_vm_options HelloWorld.
-XX:UseBranchProtection=mode
فقط لینوکس AArch64: حالت حفاظت از انشعاب (branch protection) را مشخص می‌کند.
تمام گزینه‌ها به جز none نیازمند این هستند که VM با قابلیت حفاظت از انشعاب فعال ساخته شده باشد.
علاوه بر این، برای حفاظت کامل، هرگونه کتابخانه محلی (native) ارائه‌شده توسط برنامه‌ها باید با همان سطح حفاظت کامپایل شده باشد.
آرگومان‌های ممکن mode برای این گزینه شامل موارد زیر است:
none
از حفاظت از انشعاب استفاده نکن.
این مقدار پیش‌فرض است.
standard
تمام حالت‌های حفاظت از انشعاب موجود در پلتفرم فعلی را فعال می‌کند.
pac-ret
حفاظت در برابر حملات مبتنی بر ROP را فعال می‌کند.
(فقط AArch64 8.3+)

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

-XX:AllocateInstancePrefetchLines=lines
تعداد خطوطی را که باید جلوتر از اشاره‌گر تخصیص نمونه پیش‌واکشی (prefetch) شوند تنظیم می‌کند. به‌طور پیش‌فرض، تعداد خطوط پیش‌واکشی روی ۱ تنظیم شده است:

-XX:AllocateInstancePrefetchLines=1

-XX:AllocatePrefetchDistance=size
اندازه (به بایت) فاصله پیش‌واکشی را برای تخصیص شیء تنظیم می‌کند. حافظه‌ای که قرار است با مقادیر اشیاء جدید پر شود، از آدرس آخرین شیء تخصیص‌یافته تا این فاصله پیش‌واکشی می‌شود. هر ریسه (thread) جاوا نقطه تخصیص مخصوص به خود را دارد.

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

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

-XX:AllocatePrefetchDistance=1024

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

-XX:AllocatePrefetchInstr=0

-XX:AllocatePrefetchLines=lines
تعداد خطوط حافظه نهان (cache lines) را که باید پس از آخرین تخصیص شیء با استفاده از دستورالعمل‌های پیش‌واکشی تولیدشده در کد کامپایل‌شده بارگذاری شوند، تعیین می‌کند. اگر آخرین شیء تخصیص‌یافته یک نمونه (instance) باشد، مقدار پیش‌فرض ۱ است و اگر یک آرایه باشد، این مقدار ۳ خواهد بود.

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

-XX:AllocatePrefetchLines=5

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

-XX:AllocatePrefetchStepSize=16

-XX:AllocatePrefetchStyle=style
سبک کد تولیدشده را برای دستورالعمل‌های پیش‌واکشی تنظیم می‌کند. آرگومان style یک عدد صحیح از ۰ تا ۳ است:
0
دستورالعمل‌های پیش‌واکشی تولید نشود.
1
دستورالعمل‌های پیش‌واکشی پس از هر تخصیص اجرا شود. این تنظیم پیش‌فرض است.
2
از اشاره‌گر واترمارک بلوک تخصیص محلی ریسه (TLAB) برای تعیین زمان اجرای دستورالعمل‌های پیش‌واکشی استفاده شود..TP 3 به‌ازای هر خط حافظهٔ پنهان (cache line) یک دستور prefetch تولید می‌کند.
-XX:+BackgroundCompilation
کامپایل در پس‌زمینه را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن کامپایل در پس‌زمینه، -XX:-BackgroundCompilation را مشخص کنید (این کار معادل مشخص کردن -Xbatch است).
-XX:CICompilerCount=threads
تعداد نخ‌های کامپایلر مورد استفاده برای کامپایل را تعیین می‌کند. به‌طور پیش‌فرض، تعداد نخ‌های کامپایلر به‌صورت خودکار بر اساس تعداد پردازنده‌ها و حافظهٔ در دسترس برای کد کامپایل‌شده انتخاب می‌شود. مثال زیر نحوهٔ تنظیم تعداد نخ‌ها روی ۲ را نشان می‌دهد:

-XX:CICompilerCount=2

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

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

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

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

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

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

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

-XX:CompileCommand=exclude,*.indexOf

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

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

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

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

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

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

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

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

CompilerOracle: exclude java/lang/String.indexOf

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

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

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

print java/lang/String toString

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

-XX:CompilerDirectivesFile=file
هنگام شروع برنامه، دستورالعمل‌ها را از یک فایل به پشتهٔ دستورالعمل‌ها اضافه می‌کند. بخش 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:+CompilerDirectivesPrint باید همراه با گزینهٔ -XX:UnlockDiagnosticVMOptions که گزینه‌های تشخیصی JVM را بازگشایی می‌کند، استفاده شود.

-XX:CompileOnly=methods
فهرست متدهایی (جداشده با ویرگول) را که کامپایل باید به آن‌ها محدود شود تنظیم می‌کند. تنها متدهای مشخص‌شده کامپایل می‌شوند. هر متد را با نام کامل کلاس (شامل بسته‌ها و زیربسته‌ها) مشخص کنید. برای مثال، جهت کامپایل شدنِ تنها متد length() از کلاس String و متد size() از کلاس List، از دستور زیر استفاده کنید:
-XX:CompileOnly=java/lang/String.length,java/util/List.size

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

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

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


-XX:CompileOnly=java/lang/String
-XX:CompileOnly=java/lang
-XX:CompileOnly=.length

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

-XX:InitialCodeCacheSize=32k

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

-XX:InlineSmallCode=1000

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

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

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

-XX:FreqInlineSize=size
حداکثر اندازه بایت‌کد (بر حسب بایت) یک متد داغ (hot method) را برای درون‌خطی‌سازی تنظیم می‌کند. این پرچم فقط برای کامپایلر C2 اعمال می‌شود. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت اضافه کنید. مقدار پیش‌فرض به بستر بستگی دارد. در مثال زیر این مقدار روی ۳۲۵ بایت تنظیم شده است:

-XX:FreqInlineSize=325

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

-XX:MaxInlineSize=35

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

-XX:MaxInlineSize=35

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

-XX:MaxTrivialSize=6

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

-XX:MaxTrivialSize=6

-XX:MaxNodeLimit=nodes
حداکثر تعداد گره‌های مورد استفاده در طول کامپایل یک تک‌متد را تعیین می‌کند. به‌طور پیش‌فرض این مقدار به قابلیت‌های فعال‌شده بستگی دارد. در مثال زیر حداکثر تعداد گره‌ها روی ۱۰۰,۰۰۰ تنظیم شده است:

-XX:MaxNodeLimit=100000

-XX:NonNMethodCodeHeapSize=size
اندازه بخش کد حاوی کدهای غیرمتد (nonmethod code) را به بایت تعیین می‌کند.

یک بخش کد غیرمتد شامل کدهای غیرمتد، مانند بافرهای کامپایلر و مفسر بایت‌کد است. این نوع کد برای همیشه در حافظه پنهان کد باقی می‌ماند. این پرچم فقط در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد. -XX:NonProfiledCodeHeapSize=size اندازه بخش کد (code segment) حاوی متدهای پروفایل‌نشده (nonprofiled) را بر حسب بایت تعیین می‌کند. این پرچم تنها در صورتی استفاده می‌شود که -XX:SegmentedCodeCache فعال باشد.

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

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

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

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

-XX:+PrintInlining
چاپ تصمیمات مربوط به جای‌گذاری درون‌خطی (inlining) را فعال می‌کند. این ویژگی به شما امکان می‌دهد مشاهده کنید کدام متدها به‌صورت درون‌خطی قرار می‌گیرند.

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

-XX:ReservedCodeCacheSize=size
حداکثر اندازه حافظه موقت کد (code cache) را برای کدهای کامپایل‌شده توسط JIT (بر حسب بایت) تنظیم می‌کند. برای مشخص کردن کیلوبایت حرف k یا K، برای مگابایت m یا M، و برای گیگابایت g یا G را به انتهای مقدار اضافه کنید. حداکثر اندازه پیش‌فرض حافظه موقت کد ۲۴۰ مگابایت است؛ در صورتی که کامپایل چندلایه (tiered compilation) را با گزینه -XX:-TieredCompilation غیرفعال کنید، اندازه پیش‌فرض ۴۸ مگابایت خواهد بود. این گزینه حداکثر محدودیت ۲ گیگابایت دارد؛ در غیر این صورت، خطا ایجاد می‌شود. حداکثر اندازه حافظه موقت کد نباید از اندازه اولیه آن کمتر باشد؛ گزینه -XX:InitialCodeCacheSize را ببینید.
-XX:RTMAbortRatio=abort_ratio
نسبت لغو (abort ratio) تراکنش‌های RTM را به‌صورت درصدی (%) از کل تراکنش‌های اجرایی RTM تعیین می‌کند. اگر تعداد تراکنش‌های لغوشده بیشتر از این نسبت شود، کد کامپایل‌شده وا‌بهینه‌سازی (deoptimized) می‌شود. این نسبت زمانی استفاده می‌شود که گزینه -XX:+UseRTMDeopt فعال باشد. مقدار پیش‌فرض این گزینه ۵۰ است. این بدان معناست که در صورت لغو ۵۰٪ از تمامی تراکنش‌ها، کد کامپایل‌شده وا‌بهینه‌سازی می‌شود.
-XX:RTMRetryCount=number_of_retries
تعداد دفعاتی را مشخص می‌کند که کد قفل‌گذاری RTM هنگام لغوشدن یا مشغول‌بودن، پیش از بازگشت به سازوکار قفل‌گذاری عادی، دوباره تلاش می‌شود. مقدار پیش‌فرض این گزینه ۵ است. گزینه -XX:UseRTMLocking باید فعال باشد.
-XX:+SegmentedCodeCache
بخش‌بندی حافظه موقت کد (code cache) را فعال می‌کند، که بدون آن، حافظه موقت کد از یک بخش بزرگ یکپارچه تشکیل می‌شود. با فعال بودن -XX:+SegmentedCodeCache، بخش‌های جداگانه‌ای برای کدهای غیرمتد (non-method)، متدهای پروفایل‌شده (profiled method) و متدهای پروفایل‌نشده (non-profiled method) استفاده خواهد شد. اندازه این بخش‌ها در زمان اجرا تغییر نمی‌کند. مزایای آن عبارتند از کنترل بهتر بر ردپای حافظه (memory footprint)، کاهش تکه‌تکه‌شدن کد (code fragmentation)، و بهبود عملکرد در iTLB پردازنده (instruction translation lookaside buffer) و حافظه نهان دستورالعمل به‌دلیل محلی‌سازی بهتر.

این ویژگی در صورتی که کامپایل چندلایه فعال باشد (-XX:+TieredCompilation ) و اندازه رزرو شده حافظه موقت کد (-XX:ReservedCodeCacheSize) دست‌کم ۲۴۰ مگابایت باشد، به‌طور پیش‌فرض فعال است.

-XX:StartAggressiveSweepingAt=percent
پیمایش پشته متدهای فعال را مجبور می‌کند تا در زمانی که تنها درصد مشخص‌شده‌ای از حافظه موقت کد خالی است، کدهای بدون استفاده را به‌طور تهاجمی پاکسازی کند. مقدار پیش‌فرض ۱۰٪ است.
-XX:-TieredCompilation
استفاده از کامپایل چندلایه (tiered compilation) را غیرفعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است.
-XX:UseSSE=version
استفاده از مجموعه دستورالعمل‌های SSE نسخه مشخص‌شده را فعال می‌کند. به‌طور پیش‌فرض روی بالاترین نسخه پشتیبانی‌شده موجود تنظیم می‌شود (تنها در x86).
-XX:UseAVX=version
استفاده از مجموعه دستورالعمل‌های AVX نسخه مشخص‌شده را فعال می‌کند. به‌طور پیش‌فرض روی بالاترین نسخه پشتیبانی‌شده موجود تنظیم می‌شود (تنها در x86).
-XX:+UseAES
توابع درونی (intrinsics) سخت‌افزاری AES را برای سخت‌افزارهایی که از آن پشتیبانی می‌کنند، فعال می‌کند. این گزینه در سخت‌افزارهایی که دستورالعمل‌های لازم را دارند، به‌طور پیش‌فرض فعال است. گزینه -XX:+UseAES همراه با UseAESIntrinsics استفاده می‌شود. پرچم‌هایی که توابع درونی را کنترل می‌کنند، اکنون نیازمند گزینه -XX:+UnlockDiagnosticVMOptions هستند.
-XX:+UseAESIntrinsics
توابع درونی AES را فعال می‌کند. مشخص کردن -XX:+UseAESIntrinsics معادل فعال کردن -XX:+UseAES نیز هست. برای غیرفعال کردن توابع درونی سخت‌افزاری AES، مقدار -XX:-UseAES -XX:-UseAESIntrinsics را مشخص کنید. برای نمونه، جهت فعال‌سازی AES سخت‌افزاری، از پرچم‌های زیر استفاده کنید:

-XX:+UseAES -XX:+UseAESIntrinsics

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

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

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

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

-XX:+UseSHA1Intrinsics
توابع ذاتی را برای تابع درهم‌ساز رمزنگاری SHA-1 فعال می‌کند. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
-XX:+UseSHA256Intrinsics
توابع ذاتی را برای توابع درهم‌ساز رمزنگاری SHA-224 و SHA-256 فعال می‌کند. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
-XX:+UseSHA512Intrinsics
توابع ذاتی را برای توابع درهم‌ساز رمزنگاری SHA-384 و SHA-512 فعال می‌کند. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
-XX:+UseMathExactIntrinsics
ذاتی‌سازی (intrinsification) توابع مختلف java.lang.Math.*Exact() را فعال می‌کند. به‌طور پیش‌فرض فعال است. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
-XX:+UseMultiplyToLenIntrinsic
ذاتی‌سازیِ BigInteger.multiplyToLen() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
ذاتی‌سازیِ BigInteger.squareToLen() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
ذاتی‌سازیِ BigInteger.mulAdd() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
ذاتی‌سازیِ BigInteger.montgomeryMultiply() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
ذاتی‌سازیِ BigInteger.montgomerySquare() را فعال می‌کند. به‌طور پیش‌فرض در بسترهایی که از آن پشتیبانی می‌کنند فعال است. پرچم‌هایی که توابع ذاتی را کنترل می‌کنند اکنون به گزینهٔ -XX:+UnlockDiagnosticVMOptions نیاز دارند.
-XX:+UseCMoveUnconditionally
دستورالعمل‌های CMove (اسکالر و برداری) را بدون توجه به تحلیل سودآوری تولید می‌کند.
-XX:+UseCodeCacheFlushing
تخلیهٔ حافظهٔ نهان کد را پیش از متوقف شدن کامپایلر فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تخلیهٔ حافظهٔ نهان کد پیش از متوقف شدن کامپایلر، گزینهٔ -XX:-UseCodeCacheFlushing را مشخص کنید.
-XX:+UseCondCardMark
بررسی علامت‌گذاری شدن کارت پیش از به‌روزرسانی جدول کارت را فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. این گزینه تنها باید در دستگاه‌های چندسوکت استفاده شود، جایی که کارایی برنامه‌های جاوای وابسته به عملیات‌های هم‌روند را افزایش می‌دهد.
-XX:+UseCountedLoopSafepoints
نقاط امن (safepoints) را در حلقه‌های شمارش‌شده حفظ می‌کند. مقدار پیش‌فرض آن به این بستگی دارد که آیا زباله‌روبِ انتخاب‌شده به نقاط امن با زمان تأخیر کم نیاز دارد یا خیر.
-XX:LoopStripMiningIter=number_of_iterations
تعداد تکرارها در حلقهٔ درونی strip mined را کنترل می‌کند. رویکرد Strip mining حلقه‌های شمارش‌شده را به حلقه‌های تودرتوی دو سطحی تبدیل می‌کند. نقاط امن در حلقهٔ بیرونی حفظ می‌شوند در حالی که حلقهٔ درونی می‌تواند با حداکثر سرعت اجرا شود. این گزینه حداکثر تعداد تکرارها در حلقهٔ درونی را کنترل می‌کند. مقدار پیش‌فرض 1,000 است.
-XX:LoopStripMiningIterShortLoop=number_of_iterations
بهینه‌سازی loop strip mining را کنترل می‌کند. حلقه‌هایی با تعداد تکرار کمتر از مقدار مشخص‌شده فاقد نقطهٔ امن خواهند بود. مقدار پیش‌فرض یک‌دهم مقدار -XX:LoopStripMiningIter است.
-XX:+UseFMA
توابع ذاتی FMA مبتنی بر سخت‌افزار را برای سخت‌افزارهایی که دستورالعمل‌های FMA در آن‌ها موجود است (مانند Intel و ARM64) فعال می‌کند. توابع ذاتی FMA برای متدهای java.lang.Math.fma(a, b, c) که مقدار عبارت‌های ( a * b + c ) را محاسبه می‌کنند، تولید می‌شوند.
-XX:+UseRTMDeopt
قفل‌گذاری RTM را بسته به نسبت انصراف (abort ratio) به‌طور خودکار تنظیم می‌کند. این نسبت توسط گزینهٔ -XX:RTMAbortRatio تعیین می‌شود. اگر تعداد تراکنش‌های لغوشده از نسبت انصراف فراتر رود، متد حاوی قفل، بهینه‌زدایی شده و تمام قفل‌های آن به شکل قفل‌های عادی مجدداً کامپایل می‌شوند. این گزینه به‌طور پیش‌فرض غیرفعال است. گزینهٔ -XX:+UseRTMLocking باید فعال باشد.
-XX:+UseRTMLocking
کد قفل‌گذاری حافظهٔ تراکنشی محدود (RTM) را برای تمام قفل‌های بادشده (inflated) تولید می‌کند، در حالی که سازوکار قفل‌گذاری عادی به عنوان گردانندهٔ جایگزین (fallback handler) عمل می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است. گزینه‌های مربوط به RTM تنها در پردازنده‌های x86 که از افزونه‌های همگام‌سازی تراکنشی (TSX) پشتیبانی می‌کنند در دسترس هستند.

فناوری RTM بخشی از TSX شرکت Intel است که یک افزونهٔ مجموعه دستورالعمل‌های x86 بوده و ایجاد برنامه‌های چندنخی را تسهیل می‌کند. دستورالعمل‌های جدید XBEGIN، XABORT، XEND و XTEST توسط RTM معرفی می‌شوند. دستورالعمل‌های XBEGIN و XEND مجموعه‌ای از دستورالعمل‌ها را برای اجرا در قالب یک تراکنش در بر می‌گیرند. اگر هنگام اجرای تراکنش هیچ تداخلی رخ ندهد، تغییرات حافظه و ثبات‌ها همگی با هم در دستورالعمل XEND اعمال (commit) می‌شوند. از دستورالعمل XABORT می‌توان برای لغو صریح یک تراکنش استفاده کرد و دستورالعمل XTEST بررسی می‌کند که آیا مجموعه‌ای از دستورالعمل‌ها درون یک تراکنش در حال اجرا هستند یا خیر.

یک قفل روی یک تراکنش زمانی باد می‌شود (inflated) که نخی دیگر برای دسترسی به همان تراکنش تلاش کند، و بدین ترتیب نخی را که در ابتدا درخواست دسترسی به تراکنش را نداشته مسدود می‌سازد. سازوکار RTM مستلزم آن است که مجموعه‌ای از عملیات‌های جایگزین برای مواقعی که یک تراکنش لغو شده یا با شکست مواجه می‌شود تعیین گردد. یک قفل RTM قفلی است که به سازوکار TSX واگذار شده است.

سازوکار RTM کارایی را برای قفل‌های با رقابت بالا (highly contended) و تداخل کم در یک ناحیهٔ بحرانی (کدی که نباید بیش از یک نخ به‌طور هم‌روند به آن دسترسی داشته باشد) بهبود می‌بخشد. همچنین RTM کارایی قفل‌گذاری درشت‌دانه (coarse-grain locking) را که معمولاً در برنامه‌های چندنخی عملکرد مطلوبی ندارد ارتقا می‌دهد. (قفل‌گذاری درشت‌دانه راهبرد نگه‌داشتن قفل‌ها برای مدت طولانی جهت به حداقل رساندن سربار گرفتن و آزادسازی قفل است، در حالی که قفل‌گذاری ریزدانه (fine-grained locking) راهبرد تلاش برای دستیابی به حداکثر هم‌زمانی از طریق قفل‌گذاری تنها در مواقع ضروری و آزادسازی آن در سریع‌ترین زمان ممکن است.) علاوه بر این، برای قفل‌های با رقابت اندک که توسط نخ‌های مختلف استفاده می‌شوند، RTM می‌تواند اشتراک‌گذاری کاذب خط حافظهٔ نهان (false cache line sharing) را که پینگ‌پنگ خط حافظهٔ نهان نیز نامیده می‌شود کاهش دهد. این رخداد زمانی پیش می‌آید که چندین نخ از پردازنده‌های مختلف در حال دسترسی به منابع متفاوتی باشند، اما آن منابع یک خط حافظهٔ نهان مشترک داشته باشند. در نتیجه، پردازنده‌ها مکرراً خطوط حافظهٔ نهان سایر پردازنده‌ها را باطل می‌کنند که این امر آن‌ها را مجبور می‌سازد به جای حافظهٔ نهان، اطلاعات را از حافظهٔ اصلی بخوانند.

-XX:+UseSuperWord
تبدیل عملیات‌های اسکالر به عملیات‌های superword را فعال می‌کند. فناوری Superword یک بهینه‌سازی برداری‌سازی (vectorization) است. این گزینه به‌طور پیش‌فرض فعال است. برای غیرفعال کردن تبدیل عملیات‌های اسکالر به عملیات‌های superword، گزینهٔ -XX:-UseSuperWord را مشخص کنید..SH "گزینه‌های پیشرفتهٔ سرویس‌پذیری برای جاوا (ADVANCED SERVICEABILITY OPTIONS FOR JAVA)"

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

-XX:+DisableAttachMechanism
سازوکاری را که به ابزارها اجازهٔ پیوستن (attach) به JVM می‌دهد، غیرفعال می‌کند. به‌طور پیش‌فرض، این گزینه غیرفعال است؛ به این معنی که سازوکار پیوست فعال بوده و می‌توانید از ابزارهای عیب‌یابی و رفع اشکال مانند jcmd، jstack، jmap و jinfo استفاده کنید.

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

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

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

•
غیر ویندوز: مثال زیر نحوهٔ تنظیم فایل تخلیهٔ heap را روی /var/log/java/java_heapdump.hprof نشان می‌دهد:

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

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

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

-XX:LogFile=path
مسیر و نام فایلی را که داده‌های لاگ در آن نوشته می‌شوند تعیین می‌کند. به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن hotspot.log است.
•
غیر ویندوز: مثال زیر نحوهٔ تنظیم فایل لاگ را روی /var/log/java/hotspot.log نشان می‌دهد:

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

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

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

-XX:+PrintClassHistogram
چاپ بافت‌نگار (هیستوگرام) نمونه‌های کلاس را پس از یکی از رویدادهای زیر فعال می‌کند:
•
غیر ویندوز: Control+\ (SIGQUIT)
•
ویندوز: Control+C (SIGTERM)

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

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

-XX:+PrintConcurrentLocks
چاپ قفل‌های java.util.concurrent را پس از یکی از رویدادهای زیر فعال می‌کند:
•
غیر ویندوز: Control+\ (SIGQUIT)
•
ویندوز: Control+C (SIGTERM)

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

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

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

jstat -class file:///path/hsperfdata_pid

jstat -gc file:///path/hsperfdata_pid

-XX:+UsePerfData
قابلیت perfdata را فعال می‌کند. این گزینه به‌طور پیش‌فرض فعال است تا نظارت بر JVM و آزمایش کارایی امکان‌پذیر باشد. غیرفعال کردن آن مانع از ایجاد دایرکتوری‌های hsperfdata_userid می‌شود. برای غیرفعال کردن قابلیت perfdata، گزینهٔ -XX:-UsePerfData را مشخص کنید..SH "گزینه‌های پیشرفته جمع‌آوری زباله برای جاوا (ADVANCED GARBAGE COLLECTION OPTIONS FOR JAVA)"

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

-XX:+AggressiveHeap
بهینه‌سازی هیپ جاوا را فعال می‌کند. این گزینه پارامترهای مختلف را بر اساس پیکربندی رایانه (RAM و CPU) طوری تنظیم می‌کند که برای کارهای طولانی‌مدت با تخصیص حافظه فشرده بهینه باشند. به‌طور پیش‌فرض، این گزینه غیرفعال است و اندازه‌های هیپ با تهاجم کمتری پیکربندی می‌شوند.
-XX:+AlwaysPreTouch
از ماشین مجازی درخواست می‌کند پس از دریافت هر صفحه در هیپ جاوا از سیستم‌عامل و پیش از تحویل دادن حافظه به برنامه، تک‌تک صفحات را لمس (touch / پیش‌بارگذاری) کند. به‌طور پیش‌فرض، این گزینه غیرفعال است و تمام صفحات هم‌زمان با استفاده برنامه از فضای هیپ تخصیص می‌یابند.
-XX:ConcGCThreads=threads
تعداد ریسه‌های مورد استفاده برای GC هم‌روند را تنظیم می‌کند. مقدار threads را تقریباً برابر با ۱/۴ تعداد ریسه‌های جمع‌آوری زباله موازی قرار می‌دهد. مقدار پیش‌فرض به تعداد CPUهای در دسترس JVM بستگی دارد.

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

-XX:ConcGCThreads=2

-XX:+DisableExplicitGC
گزینه‌ای را فعال می‌کند که پردازش فراخوانی‌های متد System.gc() را غیرفعال می‌سازد. این گزینه به‌طور پیش‌فرض غیرفعال است، به این معنی که فراخوانی‌های System.gc() پردازش می‌شوند. اگر پردازش فراخوانی‌های System.gc() غیرفعال باشد، JVM همچنان در صورت نیاز فرایند GC را انجام می‌دهد.
-XX:+ExplicitGCInvokesConcurrent
فراخوانی GC هم‌روند را از طریق درخواست System.gc() فعال می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است و تنها همراه با گزینه -XX:+UseG1GC قابل فعال‌سازی است.
-XX:G1AdaptiveIHOPNumInitialSamples=number
هنگامی که -XX:UseAdaptiveIHOP فعال باشد، این گزینه تعداد چرخه‌های علامت‌گذاری تکمیل‌شده‌ای را تنظیم می‌کند که برای جمع‌آوری نمونه‌ها به کار می‌روند تا زمانی که G1 مقدار بهینه -XX:InitiatingHeapOccupancyPercent را به‌صورت تطبیقی تعیین کند. پیش از آن، G1 مستقیماً از مقدار -XX:InitiatingHeapOccupancyPercent برای این منظور استفاده می‌کند. مقدار پیش‌فرض 3 است.
-XX:G1HeapRegionSize=size
اندازه نواحی‌ای را تنظیم می‌کند که هنگام استفاده از گردآورنده G1 (Garbage-First)، هیپ جاوا به آن‌ها تقسیم می‌شود. این مقدار توانی از ۲ است و می‌تواند در بازه 1 MB تا 32 MB باشد. اندازه پیش‌فرض ناحیه به‌صورت ارگونومیک بر اساس اندازه هیپ و با هدف تقریبی ۲۰۴۸ ناحیه تعیین می‌شود.

مثال زیر اندازه زیربخش‌ها را روی 16 MB تنظیم می‌کند:

-XX:G1HeapRegionSize=16m

-XX:G1HeapWastePercent=percent
درصدی از هیپ را که حاضر به هدر رفتن آن هستید تنظیم می‌کند. هنگامی که درصد فضای قابل بازیافت کمتر از درصد هدررفت هیپ باشد، Java HotSpot VM چرخه جمع‌آوری زباله ترکیبی (mixed) را آغاز نمی‌کند. پیش‌فرض 5 درصد است.
-XX:G1MaxNewSizePercent=percent
درصدی از اندازه هیپ را برای استفاده به‌عنوان بیشینه اندازه نسل جوان (young generation) تنظیم می‌کند. مقدار پیش‌فرض 60 درصد از هیپ جاوای شما است.

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

-XX:G1MixedGCCountTarget=number
تعداد هدف برای جمع‌آوری‌های زباله ترکیبی را پس از یک چرخه علامت‌گذاری تنظیم می‌کند تا نواحی قدیمی با حداکثر داده زنده به میزان G1MixedGCLIveThresholdPercent جمع‌آوری شوند. پیش‌فرض 8 جمع‌آوری زباله ترکیبی است. هدف جمع‌آوری‌های ترکیبی، ماندن در این محدوده تعداد است.
-XX:G1MixedGCLiveThresholdPercent=percent
آستانه اشغال یک ناحیه قدیمی را برای گنجانده شدن در چرخه جمع‌آوری زباله ترکیبی تنظیم می‌کند. میزان اشغال پیش‌فرض 85 درصد است.

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

-XX:G1NewSizePercent=percent
درصدی از هیپ را برای استفاده به‌عنوان کمینه اندازه نسل جوان تنظیم می‌کند. مقدار پیش‌فرض 5 درصد از هیپ جاوای شما است.

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

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

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

-XX:G1ReservePercent=20

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

پیش‌فرض، فعال است.

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

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


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

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

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

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

-XX:InitialRAMPercentage=5

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

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

S=Y/(R+2)

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

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

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

-XX:InitialSurvivorRatio=4

-XX:InitiatingHeapOccupancyPercent=percent
درصد اشغال فضای نسل قدیم (۰ تا ۱۰۰) را برای شروع نخستین چرخه‌های نشانه‌گذاری همگام در جمع‌آوری‌کننده زباله G1 تعیین می‌کند.

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

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

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

-XX:InitiatingHeapOccupancyPercent=75

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

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

-XX:MaxGCPauseMillis=500

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

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


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

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

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

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

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

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

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

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

-XX:MaxMetaspaceSize=256m

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

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

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

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

-XX:MaxRAM=2G

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

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

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

-XX:MaxRAMPercentage=75

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

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

-XX:MinRAMPercentage=75

-XX:MaxTenuringThreshold=threshold
حداکثر آستانهٔ ارتقا (tenuring threshold) را برای استفاده در تعیین اندازهٔ تطبیقی GC تنظیم می‌کند. بزرگ‌ترین مقدار ۱۵ است. مقدار پیش‌فرض برای گردآورندهٔ موازی (parallel / throughput collector) برابر با ۱۵ است.

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

-XX:MaxTenuringThreshold=10

-XX:MetaspaceSize=size
اندازهٔ فضای متادادهٔ کلاس تخصیص‌یافته را تنظیم می‌کند که در صورت فراتر رفتن از آن برای اولین بار، یک بازیافت حافظه (GC) آغاز می‌شود. این آستانه برای بازیافت حافظه، بسته به میزان متادادهٔ استفاده‌شده افزایش یا کاهش می‌یابد. اندازهٔ پیش‌فرض به بستر اجرایی (platform) بستگی دارد.
-XX:MinHeapFreeRatio=percent
حداقل درصد مجاز فضای خالی هیپ (۰ تا ۱۰۰) پس از یک رویداد GC را تعیین می‌کند. اگر فضای خالی هیپ به کمتر از این مقدار برسد، هیپ گسترش می‌یابد. به طور پیش‌فرض، این مقدار روی ۴۰٪ تنظیم شده است.

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

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

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

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

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


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

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

-XX:NewRatio=ratio
نسبت بین اندازهٔ نسل جوان (young generation) و نسل قدیم (old generation) را تعیین می‌کند. به طور پیش‌فرض، این گزینه روی ۲ تنظیم شده است. مثال زیر نحوهٔ تنظیم نسبت جوان به قدیم را روی ۱ نشان می‌دهد:

-XX:NewRatio=1

-XX:NewSize=size
اندازهٔ اولیهٔ (به بایت) هیپ را برای نسل جوان (nursery) تعیین می‌کند. حرف k یا K را برای مشخص کردن کیلوبایت، m یا M را برای مگابایت، یا g یا G را برای گیگابایت به انتهای مقدار اضافه کنید.

ناحیهٔ نسل جوان در هیپ برای اشیاء جدید استفاده می‌شود. فرایند GC در این ناحیه بیش از سایر نواحی انجام می‌گیرد. اگر اندازهٔ نسل جوان خیلی کم باشد، تعداد زیادی GC جزئی (minor GC) اجرا می‌شود. اگر اندازه بیش از حد بزرگ باشد، تنها GC کامل (full GC) اجرا خواهد شد که تکمیل آن ممکن است زمان زیادی طول بکشد. توصیه می‌شود اندازهٔ نسل جوان را بزرگ‌تر از ۲۵٪ و کمتر از ۵۰٪ اندازهٔ کلی هیپ نگه دارید.

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


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

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

-XX:ParallelGCThreads=threads
تعداد رشته‌های کاری توقف کامل (stop-the-world یا STW) را تعیین می‌کند. مقدار پیش‌فرض به تعداد پردازنده‌های در دسترس JVM و گردآورندهٔ زبالهٔ انتخاب‌شده بستگی دارد.

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

-XX:ParallelGCThreads=2

-XX:+ParallelRefProcEnabled
پردازش موازی ارجاع‌ها (parallel reference processing) را فعال می‌کند. این گزینه به طور پیش‌فرض غیرفعال است.
-XX:+PrintAdaptiveSizePolicy
چاپ اطلاعات مربوط به تعیین اندازهٔ تطبیقی نسل‌ها را فعال می‌کند. این گزینه به طور پیش‌فرض غیرفعال است.
-XX:+ScavengeBeforeFullGC
اجرای GC روی نسل جوان را پیش از هر full GC فعال می‌کند. این گزینه به طور پیش‌فرض فعال است. توصیه می‌شود آن را غیرفعال نکنید، زیرا پاک‌سازی نسل جوان پیش از یک full GC می‌تواند تعداد اشیاء قابل‌دسترس از فضای نسل قدیم به فضای نسل جوان را کاهش دهد. برای غیرفعال کردن GC روی نسل جوان پیش از هر full GC، گزینهٔ -XX:-ScavengeBeforeFullGC را مشخص کنید.
-XX:SoftRefLRUPolicyMSPerMB=time
مدت زمانی (به میلی‌ثانیه) را تعیین می‌کند که یک شیء با ارجاع soft (ارجاع‌پذیر به صورت نرم) پس از آخرین باری که به آن ارجاع داده شده، در هیپ فعال نگه داشته می‌شود. مقدار پیش‌فرض، یک ثانیه طول عمر به ازای هر مگابایت فضای خالی در هیپ است. گزینهٔ -XX:SoftRefLRUPolicyMSPerMB مقادیر صحیحی را می‌پذیرد که نشان‌دهندهٔ میلی‌ثانیه به ازای هر یک مگابایت از اندازهٔ فعلی هیپ (برای Java HotSpot Client VM) یا حداکثر اندازهٔ ممکن هیپ (برای Java HotSpot Server VM) است. این تفاوت بدین معناست که Client VM تمایل دارد به جای گسترش هیپ، ارجاع‌های soft را تخلیه کند؛ در حالی که Server VM تمایل دارد به جای تخلیهٔ ارجاع‌های soft، هیپ را گسترش دهد. در حالت دوم، مقدار گزینهٔ -Xmx تأثیر چشمگیری بر سرعت بازیافت حافظهٔ ارجاع‌های soft دارد.

مثال زیر نحوهٔ تنظیم این مقدار را بر روی ۲٫۵ ثانیه نشان می‌دهد:

-XX:SoftRefLRUPolicyMSPerMB=2500

-XX:-ShrinkHeapInSteps
اندازهٔ هیپ جاوا را به صورت تدریجی تا اندازهٔ هدف که توسط گزینهٔ -XX:MaxHeapFreeRatio مشخص شده است، کاهش می‌دهد. این گزینه به طور پیش‌فرض فعال است. در صورت غیرفعال شدن، به جای نیاز به چندین چرخهٔ بازیافت حافظه، اندازهٔ هیپ جاوا را فوراً به اندازهٔ هدف کاهش می‌دهد. اگر می‌خواهید اندازهٔ هیپ جاوا را به حداقل برسانید، این گزینه را غیرفعال کنید. هنگام غیرفعال بودن این گزینه، احتمالاً با افت کارایی مواجه خواهید شد. برای توضیحات مربوط به استفاده از گزینهٔ MaxHeapFreeRatio جهت کوچک نگه داشتن هیپ جاوا از طریق کاهش ردپای حافظه برای برنامه‌های توکار (embedded)، بخش Performance Tuning Examples را ببینید.
-XX:StringDeduplicationAgeThreshold=threshold
شیء‌های String را که به سن مشخص‌شده می‌رسند، به عنوان نامزدهای حذف داده‌های تکراری (deduplication) مشخص می‌کند. سن یک شیء معیاری است از تعداد دفعاتی که از فرایند زباله‌روبی (GC) جان سالم به در برده است. این مورد گاهی به عنوان ارتقای سنی (tenuring) نامیده می‌شود.

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

-XX:SurvivorRatio=ratio
نسبت بین اندازهٔ فضای eden و فضای survivor را تنظیم می‌کند. این گزینه به طور پیش‌فرض روی 8 تنظیم شده است. مثال زیر نحوهٔ تنظیم نسبت فضای eden/survivor به 4 را نشان می‌دهد:

-XX:SurvivorRatio=4

-XX:TargetSurvivorRatio=percent
درصد مورد نظر از فضای survivor (بین 0 تا 100) را که پس از زباله‌روبی نسل جوان استفاده می‌شود، تنظیم می‌کند. این گزینه به طور پیش‌فرض روی 50% تنظیم شده است.

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

-XX:TargetSurvivorRatio=30

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

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

-XX:TLABSize=512k

-XX:+UseAdaptiveSizePolicy
استفاده از تعیین اندازهٔ انطباقی نسل‌ها را فعال می‌کند. این گزینه به طور پیش‌فرض فعال است. برای غیرفعال کردن اندازه‌بندی انطباقی نسل‌ها، گزینهٔ -XX:-UseAdaptiveSizePolicy را مشخص کرده و اندازهٔ مخزن تخصیص حافظه را به طور صریح تعیین کنید. گزینهٔ -XX:SurvivorRatio را ببینید.
-XX:+UseG1GC
استفاده از زباله‌روب Garbage-First (G1) را فعال می‌کند. این یک زباله‌روب سروری است که برای ماشین‌های چندپردازنده‌ای با مقدار حافظهٔ رم بالا هدف‌گذاری شده است. این گزینه اهداف زمان مکث GC را با احتمال بالا برآورده می‌سازد، در حالی که توان عملیاتی خوبی را حفظ می‌کند. زباله‌روب G1 برای برنامه‌هایی پیشنهاد می‌شود که نیازمند هیپ‌های بزرگ (اندازه‌های حدود 6 گیگابایت یا بزرگ‌تر) با الزامات محدود تأخیر GC (زمان مکث پایدار و قابل پیش‌بینی زیر 0.5 ثانیه) هستند. این گزینه به طور پیش‌فرض فعال است و G1 به عنوان زباله‌روب پیش‌فرض استفاده می‌شود.
-XX:+UseGCOverheadLimit
سیاستی را فعال می‌کند که نسبت زمان صرف‌شده توسط JVM برای GC را قبل از پرتاب خطای OutOfMemoryError محدود می‌سازد. این گزینه به طور پیش‌فرض فعال است، و اگر بیش از 98% از کل زمان صرف زباله‌روبی شود و کمتر از 2% از هیپ بازیابی گردد، زباله‌روب موازی یک استثنای OutOfMemoryError صادر خواهد کرد. زمانی که هیپ کوچک است، از این ویژگی می‌توان برای جلوگیری از اجرای طولانی‌مدت برنامه‌ها با پیشرفت کم یا بدون پیشرفت استفاده کرد. برای غیرفعال کردن این گزینه، گزینهٔ -XX:-UseGCOverheadLimit را مشخص کنید.
-XX:+UseNUMA
بهینه‌سازی کارایی برنامه را در رایانه‌ای با معماری حافظه ناهمگن (NUMA) از طریق افزایش بهره‌گیری برنامه از حافظه با تأخیر کمتر فعال می‌کند. این گزینه به طور پیش‌فرض غیرفعال است و هیچ بهینه‌سازی برای NUMA انجام نمی‌شود. این گزینه تنها زمانی در دسترس است که از زباله‌روب موازی (-XX:+UseParallelGC) استفاده شود.
-XX:+UseParallelGC
استفاده از زباله‌روب موازی (parallel scavenge collector، مشهور به زباله‌روب توان عملیاتی) را فعال می‌کند تا با استفاده از پردازنده‌های متعدد، کارایی برنامهٔ شما را بهبود بخشد.

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

-XX:+UseSerialGC
استفاده از زباله‌روب ترتیبی (serial garbage collector) را فعال می‌کند. این گزینه عموماً بهترین انتخاب برای برنامه‌های کوچک و ساده‌ای است که به هیچ قابلیت خاصی در زباله‌روبی نیاز ندارند. این گزینه به طور پیش‌فرض غیرفعال است و از زباله‌روب پیش‌فرض استفاده می‌شود.
-XX:+UseSHM
فقط در لینوکس: به JVM امکان می‌دهد از حافظهٔ اشتراکی برای راه‌اندازی صفحات بزرگ (large pages) استفاده کند.

برای راه‌اندازی صفحات بزرگ، بخش Large Pages را ببینید.

-XX:+UseStringDeduplication
حذف رشته‌های تکراری (string deduplication) را فعال می‌کند. این گزینه به طور پیش‌فرض غیرفعال است. برای استفاده از این گزینه، باید زباله‌روب G1 را فعال کنید.

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

-XX:+UseTLAB
استفاده از بلوک‌های تخصیص محلی ریسه (TLABها) را در فضای نسل جوان فعال می‌کند. این گزینه به طور پیش‌فرض فعال است. برای غیرفعال کردن استفاده از TLABها، گزینهٔ -XX:-UseTLAB را مشخص کنید.
-XX:+UseZGC
استفاده از زباله‌روب Z (معروف به ZGC) را فعال می‌کند. این یک زباله‌روب با تأخیر پایین است که حداکثر زمان مکث در حد چند میلی‌ثانیه را با کمی کاهش در توان عملیاتی ارائه می‌دهد. زمان‌های مکث مستقل از اندازهٔ هیپ استفاده‌شده هستند. از هیپ‌هایی با اندازهٔ 8MB تا 16TB پشتیبانی می‌کند.
-XX:ZAllocationSpikeTolerance=factor
میزان تحمل جهش تخصیص را برای ZGC تنظیم می‌کند. این گزینه به طور پیش‌فرض روی 2.0 تنظیم شده است. این ضریب، سطح جهش‌های مورد انتظار در تخصیص حافظه را مشخص می‌کند. برای مثال، استفاده از ضریب 3.0 به این معنی است که می‌توان انتظار داشت نرخ تخصیص در هر لحظه تا سه برابر افزایش یابد.
-XX:ZCollectionInterval=seconds
حداکثر فاصلهٔ زمانی (به ثانیه) بین دو چرخهٔ GC را در هنگام استفاده از ZGC تعیین می‌کند. این گزینه به طور پیش‌فرض روی 0 (غیرفعال) تنظیم شده است.
-XX:ZFragmentationLimit=percent
حداکثر قطعه‌قطعه شدن قابل‌قبول هیپ (به درصد) را برای ZGC مشخص می‌کند. این گزینه به طور پیش‌فرض روی 25 تنظیم شده است. استفاده از مقدار کمتر باعث می‌شود فشرده‌سازی هیپ تهاجمی‌تر انجام شود تا حافظهٔ بیشتری آزاد گردد، البته به بهای مصرف زمان بیشتر توسط پردازنده.
-XX:+ZProactive
چرخه‌های پیش‌دستانهٔ GC را در هنگام استفاده از ZGC فعال می‌کند. این گزینه به طور پیش‌فرض فعال است. اگر انتظار برود که آغاز چرخهٔ زباله‌روبی کمترین تأثیر را روی برنامهٔ در حال اجرا داشته باشد، ZGC چرخهٔ پیش‌دستانه را آغاز می‌کند. این ویژگی زمانی کاربرد دارد که برنامه غالباً بیکار (idle) است یا اشیاء بسیار کمی تخصیص می‌دهد، اما شما همچنان می‌خواهید اندازهٔ هیپ را پایین نگه دارید و اجازه دهید پردازش ارجاعات انجام شود، حتی زمانی که فضای خالی زیادی روی هیپ وجود دارد.
-XX:+ZUncommit
آزادسازی (uncommit) حافظهٔ استفاده‌نشدهٔ هیپ را هنگام استفاده از ZGC فعال می‌کند. این گزینه به طور پیش‌فرض فعال است. آزادسازی حافظهٔ استفاده‌نشدهٔ هیپ موجب کاهش ردپای حافظهٔ JVM شده و آن حافظه را برای سایر فرایندها در دسترس قرار می‌دهد.
-XX:ZUncommitDelay=seconds
مدت زمانی (به ثانیه) را تعیین می‌کند که حافظهٔ هیپ قبل از آزادسازی (uncommit) باید بدون استفاده مانده باشد. این گزینه به طور پیش‌فرض روی 300 (5 دقیقه) تنظیم شده است. تخصیص قطعی (commit) و آزادسازی حافظه عملیات‌های نسبتاً هزینه‌بری هستند. استفاده از مقداری کمتر باعث می‌شود حافظهٔ هیپ زودتر آزاد شود، با این ریسک که ممکن است خیلی زود به تخصیص مجدد آن نیاز پیدا شود..SH "گزینه‌های منسوخ‌شده جاوا (DEPRECATED JAVA OPTIONS)"

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

-Xfuture
بررسی‌های سخت‌گیرانهٔ قالب فایل‌های کلاس (class-file) را که انطباق دقیق با مشخصات قالب فایل‌های کلاس را الزام می‌کند، فعال می‌سازد. توسعه‌دهندگان هنگام توسعهٔ کدهای جدید باید از این پرچم استفاده کنند. ممکن است این بررسی‌های سخت‌گیرانه‌تر در انتشارهای آینده به حالت پیش‌فرض تبدیل شوند.
-Xloggc:filename
فایلی را تنظیم می‌کند که اطلاعات تفصیلی رویدادهای GC باید برای ثبت در لاگ به آن هدایت شود. اگر هر دو گزینه با یک دستور java داده شوند، گزینهٔ -Xloggc بر -verbose:gc اولویت داشته و جایگزین آن می‌شود. گزینهٔ -Xloggc:filename با -Xlog:gc:filename جایگزین شده است. بخش Enable Logging with the JVM Unified Logging Framework را ببینید.

مثال:

-Xlog:gc:garbage-collection.log

-XX:+FlightRecorder
استفاده از Java Flight Recorder (JFR) را در زمان اجرای برنامه فعال می‌کند. از نگارش JDK 8u40 به بعد، برای استفاده از JFR دیگر نیازی به این گزینه نیست.
-XX:InitialRAMFraction=ratio
میزان حافظهٔ اولیه را که JVM ممکن است پیش از اعمال قواعد اکتشافی ارگونومی (ergonomics heuristics) برای هیپ جاوا استفاده کند، به عنوان نسبتی از حداکثر مقدار تعیین‌شده بر اساس توضیحات گزینهٔ -XX:MaxRAM تنظیم می‌کند. مقدار پیش‌فرض 64 است.

به‌جای آن از گزینهٔ -XX:InitialRAMPercentage استفاده کنید.

-XX:MaxRAMFraction=ratio
حداکثر مقدار حافظه‌ای را که JVM ممکن است پیش از اعمال قواعد اکتشافی ارگونومی برای هیپ جاوا استفاده کند، به صورت کسری از حداکثر مقدار تعیین‌شده بر اساس توضیحات گزینهٔ -XX:MaxRAM تنظیم می‌کند. مقدار پیش‌فرض 4 است.

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

به‌جای آن از گزینهٔ -XX:MaxRAMPercentage استفاده کنید.

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

به‌جای آن از گزینهٔ -XX:MinRAMPercentage استفاده کنید.

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

--illegal-access=parameter
ویژگی relaxed strong encapsulation را کنترل می‌کرد، همان‌گونه که در 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 21 حذف شده‌اند و استفاده از آن‌ها منجر به خطای زیر می‌شود:

Unrecognized VM option option-name

-XX:+ExtendedDTraceProbes
لینوکس و macOS: کاوشگرهای اضافی ابزار dtrace را که بر کارایی تأثیر می‌گذارند، فعال می‌کند. به‌طور پیش‌فرض این گزینه غیرفعال است و dtrace تنها کاوشگرهای استاندارد را انجام می‌دهد. به‌جای آن از ترکیب این پرچم‌ها استفاده کنید: -XX:+DTraceMethodProbes، -XX:+DTraceAllocProbes، -XX:+DTraceMonitorProbes.

برای فهرست و توضیحات گزینه‌های حذف‌شده در نگارش‌های پیشین، بخش Removed Java Options را در منابع زیر ببینید:

•
دستور java، نگارش 20 [https://docs.oracle.com/en/java/javase/20/docs/specs/man/java.html]
•
دستور java، نگارش 19 [https://docs.oracle.com/en/java/javase/19/docs/specs/man/java.html]
•
دستور java، نگارش 18 [https://docs.oracle.com/en/java/javase/18/docs/specs/man/java.html]
•
دستور java، نگارش 17 [https://docs.oracle.com/en/java/javase/17/docs/specs/man/java.html]
•
دستور java، نگارش 16 [https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html]
•
دستور java، نگارش 15 [https://docs.oracle.com/en/java/javase/15/docs/specs/man/java.html]
•
دستور java، نگارش 14 [https://docs.oracle.com/en/java/javase/14/docs/specs/man/java.html]
•
دستور java، نگارش 13 [https://docs.oracle.com/en/java/javase/13/docs/specs/man/java.html]
•
مرجع ابزارهای Java Platform, Standard Edition، نگارش 12 [https://docs.oracle.com/en/java/javase/12/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE]
•
مرجع ابزارهای Java Platform, Standard Edition، نگارش 11 [https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-741FC470-AA3E-494A-8D2B-1B1FE4A990D1]
•
مرجع ابزارهای Java Platform, Standard Edition، نگارش 10 [https://docs.oracle.com/javase/10/tools/java.htm#JSWOR624]
•
مرجع ابزارهای Java Platform, Standard Edition، نگارش 9 [https://docs.oracle.com/javase/9/tools/java.htm#JSWOR624]
•
مرجع ابزارهای Java Platform, Standard Edition، نگارش 8 برای Oracle JDK در Windows [https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BGBCIEFC]
•
مرجع ابزارهای Java Platform, Standard Edition، نگارش 8 برای Oracle JDK در Solaris، Linux و macOS [https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BGBCIEFC].SH "فایل‌های آرگومان خط فرمان جاوا (JAVA COMMAND-LINE ARGUMENT FILES)"

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

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

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

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

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

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

•
هر گزینه‌ای که حاوی فاصله باشد، مانند بخشی از یک مسیر، باید به طور کامل با استفاده از نویسه‌های نقل‌قول ('"') درون گیومه قرار گیرد.
•
رشته‌ای که درون گیومه قرار دارد می‌تواند شامل نویسه‌های \n، \r، \t و \f باشد. این نویسه‌ها به کدهای ASCII متناظر خود تبدیل می‌شوند.
•
اگر نام یک فایل حاوی فاصله‌های درونی است، کل نام فایل را درون علامت نقل‌قول دوتایی (double quotation) قرار دهید.
•
نام‌های فایل در یک فایل آرگومان نسبت به دایرکتوری جاری سنجیده می‌شوند، نه نسبت به محل قرارگیری فایل آرگومان.
•
از علامت هش # در فایل آرگومان برای مشخص کردن توضیحات (کامنت‌ها) استفاده کنید. تمام نویسه‌های پس از # تا انتهای خط نادیده گرفته می‌شوند.
•
پیشوندهای اضافی علامت ات‌ساین @ برای گزینه‌هایی که خود پیشوند @ دارند به عنوان نویسهٔ گریز عمل می‌کنند (اولین @ حذف می‌شود و بقیهٔ آرگومان‌ها به صورت مستقیم و عینی به اجراکننده تحویل داده می‌شوند).
•
خطوط را می‌توان با استفاده از نویسهٔ ادامه (\) در انتهای خط، ادامه داد. دو خط به یکدیگر متصل می‌شوند در حالی که فاصله‌های خالی ابتدای خط بعد حذف می‌گردند. برای جلوگیری از حذف فاصله‌های خالی ابتدای خط، می‌توان یک نویسهٔ ادامه (\) را در ستون اول قرار داد.
•
از آنجا که بک‌اسلش (\) یک نویسهٔ گریز است، یک نویسهٔ بک‌اسلش باید با یک نویسهٔ بک‌اسلش دیگر گریز داده شود (escape شود).
•
نقل‌قول ناقص مجاز است و با رسیدن به انتهای فایل (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 خاموش شد و سپس مکرراً روشن گردید؟
•
تمام فضای code heap کجا رفته است؟
•
چرا پاک‌کنندهٔ متد (method sweeper) به‌صورت مؤثر کار نمی‌کند؟

برای ایجاد این دیدگاه، قابلیت تحلیل وضعیت code heap پیاده‌سازی شده است که امکان تحلیل در لحظه و حین اجرای code heap را فراهم می‌سازد. فرآیند تحلیل به دو بخش تقسیم می‌شود. بخش اول کل code heap را بررسی کرده و تمام اطلاعاتی را که مفید یا مهم تلقی می‌شوند تجمیع می‌کند. بخش دوم شامل چندین گام مستقل است که اطلاعات جمع‌آوری‌شده را با تأکید بر جنبه‌های گوناگون داده‌ها چاپ می‌کنند. جمع‌آوری و چاپ داده‌ها بر پایهٔ «در صورت درخواست» (on request) صورت می‌گیرد.

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

jcmd pid Compiler.CodeHeap_Analytics [function] [granularity]

اگر تنها می‌خواهید بدانید وضعیت code heap پس از اجرای یک بار کاری نمونه به چه شکل درمی‌آید، می‌توانید از گزینهٔ خط فرمان زیر استفاده کنید:

-Xlog:codecache=Trace

برای مشاهده وضعیت code heap هنگامی که شرایط «CodeCache full» وجود دارد، VM را با این گزینهٔ خط فرمان راه‌اندازی کنید:

-Xlog:codecache=Debug

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

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

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

-Xlog:directive

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

چارچوب یکپارچه لاگ‌گیری ماشین مجازی جاوا (JVM) یک سیستم لاگ‌گیری مشترک را برای تمامی مؤلفه‌های JVM فراهم می‌کند. لاگ‌گیری GC در JVM تغییر یافته است تا از این چارچوب لاگ‌گیری جدید استفاده کند. نگاشت پرچم‌های قدیمی GC به پیکربندی جدید متناظر در Xlog در Convert GC Logging Flags to Xlog شرح داده شده است. علاوه بر این، لاگ‌گیری زمان اجرا (runtime) نیز برای استفاده از چارچوب یکپارچه لاگ‌گیری JVM تغییر کرده است. نگاشت پرچم‌های قدیمی لاگ‌گیری زمان اجرا به پیکربندی جدید متناظر در Xlog در Convert Runtime Logging Flags to Xlog شرح داده شده است.

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

-Xlog
لاگ‌گیری JVM را در سطح info فعال می‌کند.
-Xlog:help
نحو استفاده از -Xlog و برچسب‌ها، سطوح و آراسته‌گرهای (decorators) موجود را همراه با خط فرمان‌های نمونه و توضیحات چاپ می‌کند.
-Xlog:disable
تمام لاگ‌گیری‌ها را غیرفعال کرده و همه پیکربندی‌های چارچوب لاگ‌گیری، شامل پیکربندی پیش‌فرض برای هشدارها و خطاها را پاک می‌کند.
-Xlog[:option]
چندین آرگومان را به ترتیبی که در خط فرمان ظاهر می‌شوند اعمال می‌کند. چندین آرگومان -Xlog برای یک خروجی یکسان، یکدیگر را بر اساس ترتیب داده‌شده بازنویسی می‌کنند.

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

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

حذف tag-selection، مجموعه برچسب پیش‌فرض را روی all و سطح را روی info قرار می‌دهد.

tag[+...] all

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

مؤلفه output-options به صورت زیر است:

filecount=file-count filesize=اندازه فایل با پسوند اختیاری K، M یا G foldmultilines=<true|false>

هنگامی که foldmultilines برابر با true باشد، رویداد لاگی که شامل چند سطر است، با جایگزینی نویسه‌های خط جدید با توالی '\' و 'n' در خروجی، در یک سطر ادغام خواهد شد. نویسه‌های تک‌بک‌اسلش موجود نیز با توالی دو بک‌اسلش جایگزین می‌شوند تا تبدیل برگشت‌پذیر باشد. استفاده از این گزینه با کدگذاری نویسه UTF-8 ایمن است، اما سایر کدگذاری‌ها ممکن است به درستی کار نکنند. برای نمونه، ممکن است توالی‌های چندبایتی در Shift JIS و BIG5 را به اشتباه تبدیل کند.

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

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

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

هر پیام لاگ دارای یک سطح و یک مجموعه برچسب مرتبط است. سطح پیام نشان‌دهنده میزان جزئیات آن است، و مجموعه برچسب مشخص می‌کند که پیام شامل چه مواردی است یا به کدام مؤلفه JVM مربوط می‌شود (مانند gc، jit، یا os). نگاشت پرچم‌های GC به پیکربندی Xlog در Convert GC Logging Flags to Xlog شرح داده شده است. نگاشت پرچم‌های قدیمی لاگ‌گیری زمان اجرا به پیکربندی متناظر در Xlog در Convert Runtime Logging Flags to Xlog شرح داده شده است.

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

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

برچسب‌های لاگ موجود:

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

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

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

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

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

-Xlog:async
نوشتن تمام لاگ‌ها به‌صورت ناهمگام.

در حالت ثبت وقایع ناهمگام، محل‌های لاگ‌گیری همهٔ پیام‌ها را در یک بافر میانی صف‌بندی می‌کنند و یک ریسهٔ (thread) مستقل مسئول تخلیهٔ (flush) آن‌ها در خروجی‌های مربوطه است. بافر میانی محدود است و در صورت پر شدن بافر، پیامی که در صف قرار می‌گیرد دور ریخته می‌شود. عملیات نوشتن ورودی‌های لاگ تضمین‌شده بدون انسداد (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 شناسهٔ فرایند.
tid یا ti شناسهٔ ریسه.
level یا l سطح مرتبط با پیام لاگ.
tags یا tg مجموعه برچسب‌های مرتبط با پیام لاگ.
تبدیل پرچم‌های ثبت وقایع GC به Xlog
نگاشت پرچم‌های قدیمی ثبت وقایع GC به پیکربندی Xlog
tab( );
lw(22.4n) lw(16.5n) lw(31.2n).
پرچم قدیمی Garbage Collection (GC) پیکربندی Xlog
توضیح
T}
G1PrintHeapRegions -Xlog:gc+region=trace
قابل اعمال نیست
T}
GCLogFileSize هیچ پیکربندی‌ای در دسترس نیست
چرخش لاگ توسط چارچوب مدیریت می‌شود.
T}
NumberOfGCLogFiles قابل اعمال نیست
چرخش لاگ توسط چارچوب مدیریت می‌شود.
T}
PrintAdaptiveSizePolicy -Xlog:gc+ergo*=level
برای اکثر اطلاعات از یک level با مقدار debug، یا
برای تمام آنچه که برای PrintAdaptiveSizePolicy ثبت می‌شد
از یک level با مقدار trace استفاده کنید.
T}
PrintGC -Xlog:gc
قابل اعمال نیست
T}
PrintGCApplicationConcurrentTime -Xlog:safepoint
توجه داشته باشید که PrintGCApplicationConcurrentTime و
PrintGCApplicationStoppedTime روی همان تگ ثبت می‌شوند و
در سامانه جدید ثبت وقایع از هم جدا نیستند.
T}
PrintGCApplicationStoppedTime -Xlog:safepoint
توجه داشته باشید که PrintGCApplicationConcurrentTime و
PrintGCApplicationStoppedTime روی همان تگ ثبت می‌شوند و
در سامانه جدید ثبت وقایع از هم جدا نیستند.
T}
PrintGCCause قابل اعمال نیست
علت GC اکنون همیشه ثبت می‌شود.
T}
PrintGCDateStamps قابل اعمال نیست
برچسب‌های تاریخ توسط چارچوب ثبت می‌شوند.
T}
PrintGCDetails -Xlog:gc*
قابل اعمال نیست
T}
PrintGCID قابل اعمال نیست
شناسه GC اکنون همیشه ثبت می‌شود.
T}
PrintGCTaskTimeStamps -Xlog:gc+task*=debug
قابل اعمال نیست
T}
PrintGCTimeStamps قابل اعمال نیست
برچسب‌های زمانی توسط چارچوب ثبت می‌شوند.
T}
PrintHeapAtGC -Xlog:gc+heap=trace
قابل اعمال نیست
T}
PrintReferenceGC -Xlog:gc+ref*=debug
توجه داشته باشید که در ثبت وقایع قدیمی، PrintReferenceGC تنها
در صورتی اثر داشت که PrintGCDetails نیز فعال شده باشد.
T}
PrintStringDeduplicationStatistics `-Xlog:gc+stringdedup*=debug
` قابل اعمال نیست
T}
PrintTenuringDistribution -Xlog:gc+age*=level
برای بیشترین اطلاعات مرتبط از یک level با مقدار debug،
یا برای تمام آنچه که برای PrintTenuringDistribution ثبت می‌شد
از یک level با مقدار trace استفاده کنید.
T}
UseGCLogFileRotation قابل اعمال نیست
آنچه که برای PrintTenuringDistribution ثبت می‌شد.
T}
این پرچم‌های قدیمی دیگر شناخته نمی‌شوند و در صورت استفادهٔ مستقیم باعث خطا خواهند شد.
در عوض از معادل وقایع‌نگاری یکپارچهٔ (unified logging) آن‌ها استفاده کنید.
نگاشت پرچم‌های وقایع‌نگاری زمان اجرا به پیکربندی Xlog
tab( );
lw(15.0n) lw(20.2n) lw(34.7n).
پرچم زمان اجرای قدیمی پیکربندی Xlog
توضیحات
T}
TraceExceptions -Xlog:exceptions=info
اعمال نمی‌شود
T}
TraceClassLoading -Xlog:class+load=level
برای اطلاعات معمولی از level=info، یا
برای اطلاعات اضافی از level=debug استفاده کنید.
در نحو Unified Logging، پرچم -verbose:class برابر با
-Xlog:class+load=info,class+unload=info است.
T}
TraceClassLoadingPreorder -Xlog:class+preorder=debug
اعمال نمی‌شود
T}
TraceClassUnloading -Xlog:class+unload=level
برای اطلاعات معمولی از level=info، یا
برای اطلاعات اضافی از level=trace استفاده کنید.
در نحو Unified Logging، پرچم -verbose:class برابر با
-Xlog:class+load=info,class+unload=info است.
T}
VerboseVerification -Xlog:verification=info
اعمال نمی‌شود
T}
TraceClassPaths -Xlog:class+path=info
اعمال نمی‌شود
T}
TraceClassResolution -Xlog:class+resolve=debug
اعمال نمی‌شود
T}
TraceClassInitialization -Xlog:class+init=info
اعمال نمی‌شود
T}
TraceLoaderConstraints -Xlog:class+loader+constraints=info
اعمال نمی‌شود
T}
TraceClassLoaderData -Xlog:class+loader+data=level
برای اطلاعات معمولی از level=debug یا
برای اطلاعات اضافی از level=trace استفاده کنید.
T}
TraceSafepointCleanupTime -Xlog:safepoint+cleanup=info
اعمال نمی‌شود
T}
TraceSafepoint -Xlog:safepoint=debug
اعمال نمی‌شود
T}
TraceMonitorInflation -Xlog:monitorinflation=debug
اعمال نمی‌شود
T}
TraceRedefineClasses -Xlog:redefine+class*=level
سطوح level=info، debug و trace
مقادیر فزاینده‌ای از اطلاعات را ارائه می‌دهند.
T}
موارد زیر مثال‌هایی از کاربرد -Xlog هستند.
-Xlog
تمام پیام‌ها را با استفاده از سطح info و با تزیینات uptime، levels و tags در stdout ثبت می‌کند.
این معادل استفاده از دستور زیر است:
-Xlog:all=info:stdout:uptime,levels,tags
-Xlog:gc
پیام‌های دارای برچسب gc را با سطح info در stdout ثبت می‌کند.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning همچنان برقرار است.
-Xlog:gc,safepoint
پیام‌های دارای هر یک از برچسب‌های gc یا safepoint را با سطح info و تزیینات پیش‌فرض در stdout ثبت می‌کند.
پیام‌هایی که همزمان هر دو برچسب gc و safepoint را دارند ثبت نخواهند شد.
-Xlog:gc+ref=debug
پیام‌هایی را که همزمان هر دو برچسب gc و ref را دارند، با استفاده از سطح debug و تزیینات پیش‌فرض در stdout ثبت می‌کند.
پیام‌هایی که تنها یکی از این دو برچسب را دارند ثبت نخواهند شد.
-Xlog:gc=debug:file=gc.txt:none
پیام‌های دارای برچسب gc را با سطح debug و بدون هیچ تزیینی در فایلی به نام gc.txt ثبت می‌کند.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning همچنان برقرار است.
-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pids:filecount=5,filesize=1024
پیام‌های دارای برچسب gc را با سطح trace در مجموعه‌ای چرخشی از ۵ فایل با اندازهٔ ۱ مگابایت با نام پایهٔ gctrace.txt ثبت کرده و از تزیینات uptimemillis و pid استفاده می‌کند.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning همچنان برقرار است.
-Xlog:gc::uptime,tid
پیام‌های دارای برچسب gc را با سطح پیش‌فرض 'info' در خروجی پیش‌فرض stdout ثبت کرده و از تزیینات uptime و tid استفاده می‌کند.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning همچنان برقرار است.
-Xlog:gc*=info,safepoint*=off
پیام‌های دارای دست‌کم برچسب gc را با استفاده از سطح info ثبت می‌کند، اما ثبت وقایع پیام‌های دارای برچسب safepoint را خاموش می‌کند.
پیام‌هایی که هر دو برچسب gc و safepoint را دارند ثبت نخواهند شد.
-Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt
تمام ثبت وقایع، شامل هشدارها و خطاها را غیرفعال می‌کند و سپس ثبت پیام‌های دارای برچسب safepoint را با سطح trace در فایل safepointtrace.txt فعال می‌سازد.
پیکربندی پیش‌فرض اعمال نمی‌شود، چرا که خط فرمان با -Xlog:disable آغاز شده است.
مثال‌های پیچیده از کاربرد -Xlog
موارد زیر چند مثال پیچیده از به‌کارگیری گزینهٔ -Xlog را شرح می‌دهند.
-Xlog:gc+class*=debug
پیام‌های دارای دست‌کم برچسب‌های gc و class را با استفاده از سطح debug در stdout ثبت می‌کند.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning همچنان برقرار است.
-Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt
پیام‌های دارای دست‌کم برچسب‌های gc و meta را با سطح trace در فایل metatrace.txt ثبت می‌کند اما تمام پیام‌های دارای برچسب class را خاموش می‌نماید.
پیام‌های دارای برچسب‌های gc، meta و class ثبت نخواهند شد زیرا class* روی off تنظیم شده است.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning به جز مواردی که شامل class هستند برقرار است.
-Xlog:gc+meta=trace
پیام‌هایی را که دقیقاً دارای برچسب‌های gc و meta هستند، با استفاده از سطح trace در stdout ثبت می‌کند.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning همچنان برقرار است.
-Xlog:gc+class+heap*=debug,meta*=warning,threads*=off
پیام‌های دارای دست‌کم برچسب‌های gc، class و heap را با سطح trace در stdout ثبت می‌کند اما پیام‌های دارای برچسب meta را تنها با سطح مربوطه ثبت می‌نماید.
پیکربندی پیش‌فرض برای تمام پیام‌های دیگر در سطح warning به جز مواردی که شامل threads هستند برقرار است.
"اعتبارسنجی آرگومان‌های پرچم ماشین مجازی جاوا (VALIDATE JAVA VIRTUAL MACHINE FLAG ARGUMENTS)"
شما از مقادیر ارائه‌شده به تمامی پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) برای اعتبارسنجی استفاده می‌کنید و اگر مقدار ورودی نامعتبر یا خارج از محدوده باشد، پیام خطای مناسبی نمایش داده می‌شود.
چه این مقادیر به‌صورت ارگونومیک، در خط فرمان، توسط یک ابزار ورودی یا از طریق APIها (برای مثال کلاس‌های موجود در بستهٔ java.lang.management) تنظیم شده باشند، مقادیر ارائه‌شده به تمامی پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) اعتبارسنجی می‌شوند.
ارگونومی در راهنمای Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide شرح داده شده است.
محدوده‌ها و قیود یا در زمان مقداردهی اولیهٔ 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}

این موضوع به شناسایی پرچم‌هایی که نیاز به پیاده‌سازی دارند کمک می‌کند.
چارچوب آزمون خودکار می‌تواند پرچم‌هایی را که مقداری ندارند و پیاده‌سازی نشده‌اند نادیده بگیرد..SH "صفحات بزرگ (LARGE PAGES)"
شما از صفحات بزرگ (large pages)، که با نام صفحات عظیم (huge pages) نیز شناخته می‌شوند، به عنوان صفحاتی از حافظه استفاده می‌کنید که به طور قابل توجهی بزرگ‌تر از اندازه استاندارد صفحه حافظه هستند (که بسته به پردازنده و سیستم‌عامل متفاوت است).
صفحات بزرگ بافرهای ترجمه آدرس (Translation-Lookaside Buffers یا TLB) پردازنده را بهینه‌سازی می‌کنند.
یک بافر ترجمه آدرس (TLB) حافظه نهانِ ترجمه صفحه است که جدیدترین ترجمه‌های آدرس مجازی به فیزیکیِ استفاده‌شده را نگه می‌دارد.
TLB یک منبع سیستمی کمیاب است.
از دست رفتن داده در TLB (اصطلاحاً TLB miss) می‌تواند هزینه‌بر باشد، زیرا پردازنده باید از جدول سلسله‌مراتبی صفحات بخواند، که ممکن است نیازمند چندین بار دسترسی به حافظه باشد.
با استفاده از اندازه صفحه حافظه بزرگ‌تر، یک مدخل واحد TLB می‌تواند محدوده حافظه بزرگ‌تری را نشان دهد.
این امر منجر به فشار کمتری روی TLB می‌شود و برنامه‌های پرمصرف از نظر حافظه ممکن است عملکرد بهتری داشته باشند.
با این حال، استفاده از صفحات بزرگ می‌تواند تأثیر منفی بر عملکرد سیستم بگذارد.
برای نمونه، هنگامی که مقدار زیادی از حافظه توسط یک برنامه پین (قفل) می‌شود، ممکن است کمبود حافظه معمولی ایجاد کند و باعث صفحه‌بندی (paging) بیش از حد در سایر برنامه‌ها شده و کل سیستم را کُند سازد.
همچنین، سیستمی که برای مدتی طولانی روشن بوده است ممکن است دچار تکه‌تکه‌شدن (fragmentation) بیش از حد شود، که این موضوع می‌تواند رزرو حافظه کافی برای صفحات بزرگ را غیرممکن سازد.
وقتی این اتفاق می‌افتد، سیستم‌عامل یا JVM به استفاده از صفحات معمولی بازمی‌گردد.
لینوکس و ویندوز از صفحات بزرگ پشتیبانی می‌کنند.
"پشتیبانی از صفحات بزرگ در لینوکس (Large Pages Support for Linux)"
لینوکس از نسخه 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

محیط بالا از صفحات بزرگ ۲ مگابایتی و ۱ گیگابایتی پشتیبانی می‌کند، اما آن‌ها باید پیکربندی شوند تا JVM بتواند از آن‌ها استفاده کند.
هنگام استفاده از صفحات بزرگ و عدم فعال‌سازی صفحات عظیم شفاف (گزینه -XX:+UseTransparentHugePages)، تعداد صفحات بزرگ باید از قبل تخصیص داده شود.
برای نمونه، جهت فعال‌سازی ۸ گیگابایت حافظه با پشتیبانی صفحات بزرگ ۲ مگابایتی، با کاربر root وارد شوید و دستور زیر را اجرا کنید:
# echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
همواره توصیه می‌شود پس از درخواست، مقدار nr_hugepages را بررسی کنید تا مطمئن شوید هسته قادر به تخصیص تعداد صفحات بزرگ درخواستی بوده است.
هنگام استفاده از گزینه -XX:+UseSHM برای فعال‌سازی صفحات بزرگ، همچنین باید مطمئن شوید پارامتر SHMMAX طوری پیکربندی شده است که امکان تخصیص بخش‌های حافظه مشترک به اندازه کافی بزرگ را فراهم کند.
برای مجاز کردن حداکثر یک بخش مشترک ۸ گیگابایتی، با کاربر root وارد شوید و دستور زیر را اجرا کنید:
# echo 8589934592 > /proc/sys/kernel/shmmax
در برخی محیط‌ها این کار ضروری نیست زیرا مقدار پیش‌فرض به اندازه کافی بزرگ است، اما اطمینان از اینکه مقدار به اندازه کافی بزرگ باشد تا میزان حافظه در نظر گرفته شده برای پشتیبانی توسط صفحات بزرگ را دربرگیرد، حائز اهمیت است.
نکته: مقادیر موجود در /proc و /sys پس از راه‌اندازی مجدد سیستم بازنشانی می‌شوند، بنابراین ممکن است بخواهید آن‌ها را در یک اسکریپت مقداردهی اولیه (برای نمونه، rc.local یا sysctl.conf) تنظیم کنید.
اگر پارامترهای هسته سیستم‌عامل را برای فعال کردن استفاده از صفحات بزرگ پیکربندی کنید، فرآیندهای جاوا ممکن است صفحات بزرگ را علاوه بر Java heap، برای سایر بخش‌های داخلی نیز تخصیص دهند، برای نمونه:
• 2
حافظه نهان کد (Code cache)
• 2
بیت‌مپ‌های نشانه‌گذاری (Marking bitmaps)
در نتیجه، اگر پارامتر nr_hugepages را برابر با اندازه Java heap پیکربندی کنید، همچنان ممکن است JVM در تخصیص heap با استفاده از صفحات بزرگ با شکست مواجه شود، زیرا سایر بخش‌ها مانند حافظه نهان کد (code cache) ممکن است از قبل برخی از صفحات بزرگ پیکربندی‌شده را مصرف کرده باشند.
"پشتیبانی از صفحات بزرگ در ویندوز (Large Pages Support for Windows)"
برای استفاده از پشتیبانی صفحات بزرگ در ویندوز، مدیر سیستم (administrator) ابتدا باید امتیازات بیشتری را به کاربری که برنامه را اجرا می‌کند اختصاص دهد:
"1." 3
گزینه Control Panel، سپس Administrative Tools و در ادامه Local Security Policy را انتخاب کنید.
"2." 3
گزینه Local Policies و سپس User Rights Assignment را انتخاب کنید.
"3." 3
روی Lock pages in memory دوبار کلیک کنید، سپس کاربران و/یا گروه‌ها را اضافه نمایید.
"4." 3
سیستم خود را مجدداً راه‌اندازی (Reboot) کنید.
توجه داشته باشید که این مراحل حتی در صورتی که مدیر سیستم (administrator) برنامه را اجرا کند نیز الزامی است، زیرا مدیران سیستم به طور پیش‌فرض امتیاز قفل کردن صفحات در حافظه را ندارند..SH "اشتراک‌گذاری داده‌های کلاس برنامه (APPLICATION CLASS DATA SHARING)"
قابلیت «اشتراک‌گذاری داده‌های کلاس برنامه» (AppCDS) کلاس‌های استفاده‌شده توسط برنامه‌های شما را در یک فایل بایگانی ذخیره می‌کند.
از آنجا که این کلاس‌ها در قالبی ذخیره می‌شوند که می‌توانند بسیار سریع بارگذاری شوند (در مقایسه با کلاس‌های ذخیره‌شده در یک فایل JAR)، AppCDS می‌تواند زمان راه‌اندازی برنامه‌های شما را بهبود بخشد.
علاوه بر این، AppCDS می‌تواند با به اشتراک گذاشتن بخش‌هایی از این کلاس‌ها بین چندین فرایند، ردپای حافظه زمان اجرا را کاهش دهد.
کلاس‌ها در بایگانی CDS در قالبی بهینه‌شده ذخیره می‌شوند که حدود ۲ تا ۵ برابر بزرگ‌تر از کلاس‌های ذخیره‌شده در فایل‌های JAR یا تصویر زمان اجرای JDK است.
بنابراین، ایده مناسبی است که تنها آن دسته از کلاس‌هایی را بایگانی کنید که واقعاً توسط برنامه شما استفاده می‌شوند.
این‌ها معمولاً تنها بخش کوچکی از تمام کلاس‌های موجود هستند.
برای مثال، برنامه شما ممکن است تنها از چند API ارائه‌شده توسط یک کتابخانه بزرگ استفاده کند.
"استفاده از بایگانی‌های CDS"
به‌طور پیش‌فرض، در بیشتر توزیع‌های 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>
• 2
بخش <static_archive> جایگزین بایگانی پیش‌فرض CDS می‌شود.
• 2
بخش <dynamic_archive> کلاس‌های اضافی را فراهم می‌کند که می‌توانند علاوه بر کلاس‌های موجود در <static_archive> بارگذاری شوند.
• 2
در ویندوز، جداکننده مسیر فوق (:) باید با ; جایگزین شود.
(نام‌های "static" (ایستا) و "dynamic" (پویا) به دلایل تاریخی استفاده شده‌اند.
تنها اهمیت آن‌ها این است که بایگانی "static" ابتدا بارگذاری می‌شود و بایگانی "dynamic" در مرتبه دوم بارگذاری می‌شود).
ماشین مجازی JVM می‌تواند حداکثر از دو بایگانی استفاده کند.
برای استفاده از تنها یک <static_archive>، می‌توانید بخش <dynamic_archive> را حذف کنید:
-XX:SharedArchiveFile=<static_archive>
برای سهولت، <dynamic_archive> مکان <static_archive> را ثبت می‌کند.
بنابراین، می‌توانید تنها با نوشتن مورد زیر، <static_archive> را حذف کنید:
-XX:SharedArchiveFile=<dynamic_archive>
"ایجاد دستی بایگانی‌های CDS"
بایگانی‌های CDS را می‌توان با استفاده از چندین روش به‌صورت دستی ایجاد کرد:
• 2
-Xshare:dump
• 2
-XX:ArchiveClassesAtExit
• 2
jcmd VM.cds
یک عملیات مشترک در تمام این روش‌ها یک «اجرای آزمایشی» ("trial run") است، که در آن برنامه را یک بار اجرا می‌کنید تا کلاس‌هایی که باید در بایگانی ذخیره شوند تعیین گردند.
"ایجاد یک فایل بایگانی CDS ایستا با -Xshare:dump"
مراحل زیر یک فایل بایگانی CDS ایستا ایجاد می‌کند که شامل تمام کلاس‌های استفاده‌شده توسط برنامه test.Hello است.
"1." 3
فهرستی از تمام کلاس‌های استفاده‌شده توسط برنامه test.Hello ایجاد کنید.
دستور زیر فایلی به نام hello.classlist ایجاد می‌کند که حاوی فهرستی از تمام کلاس‌های استفاده‌شده توسط این برنامه است:
4
java -Xshare:off -XX:DumpLoadedClassList=hello.classlist -cp hello.jar test.Hello
مسیر کلاسی که توسط پارامتر -cp مشخص می‌شود باید تنها شامل فایل‌های JAR باشد.
"2." 3
یک بایگانی ایستا به نام hello.jsa ایجاد کنید که حاوی تمام کلاس‌های موجود در hello.classlist باشد:
4
java -Xshare:dump -XX:SharedArchiveFile=hello.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar
"3." 3
برنامه test.Hello را با بایگانی hello.jsa اجرا کنید:
4
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello
"4." 3
اختیاری بررسی کنید که برنامه test.Hello از کلاس موجود در بایگانی اشتراکی hello.jsa استفاده می‌کند:
4
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar -Xlog:class+load test.Hello
خروجی این دستور باید شامل متن زیر باشد:
[info][class,load] test.Hello source: shared objects file
مزایای آرشیوهای پویای CDS عبارتند از:
• 2
آن‌ها معمولاً فضای دیسک کمتری مصرف می‌کنند، زیرا نیازی به ذخیره کلاس‌هایی که از قبل در آرشیو ایستا موجود هستند ندارند.
• 2
آن‌ها در مقایسه با آرشیو ایستای مشابه، با یک مرحله کمتر ایجاد می‌شوند.
مراحل زیر یک فایل آرشیو پویای CDS ایجاد می‌کنند که شامل کلاس‌های مورد استفاده توسط برنامه test.Hello است، به استثنای مواردی که از قبل در آرشیو پیش‌فرض CDS قرار دارند.
"1." 3
ایجاد یک آرشیو پویای CDS با نام hello.jsa که شامل تمام کلاس‌های موجود در hello.jar است که توسط برنامه test.Hello بارگذاری شده‌اند:
4
java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello
"2." 3
اجرای برنامه test.Hello با آرشیو اشتراکی hello.jsa:
4
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello
"3." 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
(در Windows، جداکننده مسیر : در بالا باید با ; جایگزین شود)
همان‌طور که در بالا اشاره شد، می‌توان از نام آرشیو ایستا صرف‌نظر کرد:
java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello
ایجاد فایل‌های آرشیو CDS با jcmd
دو بخش قبلی برای ایجاد یک آرشیو CDS، نیازمند تغییر اسکریپت راه‌اندازی برنامه هستند.
گاهی اوقات این کار ممکن است دشوار باشد، به عنوان مثال اگر مسیر کلاس (class path) برنامه توسط روال‌های پیچیده‌ای تنظیم شده باشد.
دستور 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
ایجاد فایل آرشیو پویای CDS با -XX:+AutoCreateSharedArchive
گزینه -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 همخوانی داشته باشد.
اگر قصد دارید از این ویژگی به همراه یک آرشیو موجود استفاده کنید، باید مطمئن شوید که آرشیو حداقل با نسخه ۱۹ از JDK ساخته شده است..SS محدودیت‌های Class Path و Module Path
• 2
نه مسیر کلاس (-classpath و
-Xbootclasspath/a) و نه مسیر ماژول
(--module-path) نمی‌توانند شامل دایرکتوری‌های غیرخالی باشند.
• 2
در --module-path فقط از فایل‌های JAR ماژولار پشتیبانی می‌شود.
ماژول‌های بازشده (Exploded modules) پشتیبانی نمی‌شوند.
• 2
مسیر کلاسی که در زمان ایجاد آرشیو استفاده شده است باید با مسیر کلاس استفاده‌شده در
زمان اجرا یکسان باشد (یا پیشوندی از آن باشد).
(هیچ الزامی از این دست برای مسیر ماژول وجود ندارد.)
• 2
اگر هر یک از فایل‌های JAR در مسیر کلاس یا مسیر ماژول پس از ایجاد آرشیو تغییر کنند،
آرشیو CDS نمی‌تواند بارگیری شود.
• 2
در صورت تعیین هر یک از گزینه‌های VM شامل --upgrade-module-path،
--patch-module یا --limit-modules، قابلیت CDS
غیرفعال می‌شود.
این بدان معناست که JVM بدون بارگیری هیچ آرشیو CDS اجرا خواهد شد.
علاوه بر این، اگر تلاش کنید با تعیین هر یک از این ۳
گزینه یک آرشیو CDS ایجاد کنید، JVM یک خطا گزارش خواهد کرد.
"مثال‌های بهینه‌سازی کارایی (PERFORMANCE TUNING EXAMPLES)"
می‌توانید از گزینه‌های پیشرفته زمان اجرای جاوا برای بهینه‌سازی کارایی برنامه‌های خود استفاده کنید.
تنظیم برای توان عملیاتی بالاتر
برای دستیابی به عملکرد توان عملیاتی بالاتر در برنامه خود، از دستورها و گزینه‌های پیشرفته زیر استفاده کنید:
java -server -XX:+UseParallelGC -XX:+UseLargePages -Xmn10g -Xms26g -Xmx26g
تنظیم برای زمان پاسخ‌دهی کوتاه‌تر
برای دستیابی به زمان‌های پاسخ‌دهی کوتاه‌تر برای برنامه خود، از دستورها و گزینه‌های پیشرفته زیر استفاده کنید:
java -XX:+UseG1GC -XX:MaxGCPauseMillis=100
کوچک نگه‌داشتن هیپ جاوا و کاهش ردپای حافظه پویای برنامه‌های تعبیه‌شده
از گزینه‌های پیشرفته زمان اجرای زیر برای کوچک نگه‌داشتن هیپ جاوا
و کاهش ردپای پویای برنامه‌های تعبیه‌شده استفاده کنید:
-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5
نکته: مقادیر پیش‌فرض برای این دو گزینه به ترتیب ۷۰٪ و ۴۰٪
است.
از آنجا که هنگام استفاده از این تنظیمات ممکن است افت کارایی رخ دهد،
باید با کاهش این مقادیر تا حد امکان، اندازه ردپای حافظه را بدون ایجاد افت
کارایی غیرقابل قبول بهینه‌سازی کنید.
"وضعیت خروج (EXIT STATUS)"
هنگامی که اجراکننده با آرگومان‌های نادرست، خطاهای جدی یا استثناهای پرتاب‌شده از سوی JVM فراخوانی شود،
معمولاً مقادیر خروج زیر را بازمی‌گرداند.
با این حال، یک برنامه جاوا می‌تواند با استفاده از فراخوانی رابط برنامه‌نویسی System.exit(exitValue)
هر مقداری را بازگرداند.
این مقادیر عبارتند از:
• 2
0: اتمام موفقیت‌آمیز
• 2
>0: خطایی رخ داده است
2023 JDK 21