'\" t
.\" Automatically generated by Pandoc 3.10.2
.\"
.TH "JAVA" "1" "2026" "JDK 26.0.2.1" "JDK Commands"
.SH "نام (NAME)"
java \- اجرای یک برنامه جاوا
.SH "خلاصه دستور (SYNOPSIS)"
برای اجرای یک فایل کلاس:
.PP
\f[CR]java\f[R] [\f[I]options\f[R]] \f[I]mainclass\f[R] [\f[I]args\f[R]
\&...]
.PP
برای اجرای کلاس اصلی در یک فایل JAR:
.PP
\f[CR]java\f[R] [\f[I]options\f[R]] \f[CR]\-jar\f[R] \f[I]jarfile\f[R]
[\f[I]args\f[R] ...]
.PP
برای اجرای کلاس اصلی در یک ماژول:
.PP
\f[CR]java\f[R] [\f[I]options\f[R]] \f[CR]\-m\f[R]
\f[I]module\f[R][\f[CR]/\f[R]\f[I]mainclass\f[R]] [\f[I]args\f[R] ...]
.PP
یا
.PP
\f[CR]java\f[R] [\f[I]options\f[R]] \f[CR]\-\-module\f[R]
\f[I]module\f[R][\f[CR]/\f[R]\f[I]mainclass\f[R]] [\f[I]args\f[R] ...]
.PP
برای اجرای یک برنامه از فایل منبع:
.PP
\f[CR]java\f[R] [\f[I]options\f[R]] \f[I]source\-file\f[R]
[\f[I]args\f[R] ...]
.TP
\f[I]options\f[R]
اختیاری: گزینه‌های خط فرمان را مشخص می‌کند که با فاصله (space) از هم جدا می‌شوند.
برای شرح گزینه‌های موجود، به \f[B]Overview of Java Options\f[R] مراجعه کنید.
.TP
\f[I]mainclass\f[R]
نام کلاسی را که باید اجرا شود مشخص می‌کند.
ورودی‌های خط فرمان پس از \f[CR]classname\f[R]، آرگومان‌های متد اصلی (main) هستند.
.TP
\f[CR]\-jar\f[R] \f[I]jarfile\f[R]
برنامه‌ای را که در یک فایل JAR بسته‌بندی شده است اجرا می‌کند.
آرگومان \f[I]jarfile\f[R] نام یک فایل JAR است که شامل مانیفستی با سطری به شکل
\f[CR]Main\-Class:\f[R]\f[I]classname\f[R] می‌باشد؛ این سطر کلاسی را که دارای متد
\f[CR]public static void main(String[] args)\f[R] بوده و به عنوان نقطه آغازین برنامه شما عمل می‌کند تعریف می‌نماید.
هنگامی که از \f[CR]\-jar\f[R] استفاده می‌کنید، فایل JAR مشخص‌شده منبع تمامی کلاس‌های کاربر است و سایر تنظیمات مسیر کلاس (class path) نادیده گرفته می‌شوند.
اگر از فایل‌های JAR استفاده می‌کنید، به \f[B]jar\f[R] مراجعه کنید.
.TP
\f[CR]\-m\f[R] یا \f[CR]\-\-module\f[R] \f[I]module\f[R][\f[CR]/\f[R]\f[I]mainclass\f[R]]
کلاس اصلی را در ماژول مشخص‌شده توسط \f[I]mainclass\f[R] (در صورت تعیین)، یا در صورت عدم تعیین، مقدار موجود در \f[I]module\f[R] اجرا می‌کند.
به عبارت دیگر، \f[I]mainclass\f[R] می‌تواند زمانی استفاده شود که توسط ماژول مشخص نشده باشد، یا برای بازنویسی مقدار تعیین‌شده به کار رود.
.RS
به \f[B]Standard Options for Java\f[R] مراجعه کنید.
.RE
.TP
\f[I]source\-file\f[R]
تنها برای اجرای برنامه‌های مبتنی بر فایل منبع استفاده می‌شود.
فایل منبعی را که در زمان استفاده از حالت source\-file حاوی کلاس اصلی است، مشخص می‌کند.
به \f[B]Using Source\-File Mode to Launch Source\-Code Programs\f[R] مراجعه کنید.
.TP
\f[I]args\f[R] ...
اختیاری: آرگومان‌های پس از \f[I]mainclass\f[R]،
\f[I]source\-file\f[R]، \f[CR]\-jar\f[R] \f[I]jarfile\f[R]، و
\f[CR]\-m\f[R] یا \f[CR]\-\-module\f[R]
\f[I]module\f[R]\f[CR]/\f[R]\f[I]mainclass\f[R] به عنوان آرگومان به کلاس اصلی ارسال می‌شوند.
.SH "توضیحات (DESCRIPTION)"
دستور \f[CR]java\f[R] یک برنامه کاربردی جاوا را اجرا می‌کند.
این کار با راه‌اندازی ماشین مجازی جاوا (JVM)، بارگذاری کلاس مشخص‌شده و فراخوانی متد \f[CR]main()\f[R] آن کلاس صورت می‌گیرد.
این متد باید به صورت \f[CR]public\f[R] و \f[CR]static\f[R] تعریف شده باشد، نباید هیچ مقداری را بازگرداند، و باید یک آرایه \f[CR]String\f[R] را به عنوان پارامتر بپذیرد.
تعریف این متد به شکل زیر است:
.RS
.PP
\f[CR]public static void main(String[] args)\f[R]
.RE
.PP
در حالت فایل منبع (source\-file mode)، دستور \f[CR]java\f[R] می‌تواند کلاسی را که درون یک فایل منبع اعلان شده است اجرا کند.
برای توضیحات مربوط به استفاده از حالت فایل منبع، به \f[B]Using Source\-File Mode to Launch Source\-Code Programs\f[R] مراجعه کنید.
.RS
.PP
\f[B]نکته:\f[R] می‌توانید از متغیر محیطی اجراکننده \f[CR]JDK_JAVA_OPTIONS\f[R] برای الصاق محتوای آن به ابتدای خط فرمان واقعی اجراکننده \f[CR]java\f[R] استفاده کنید.
به \f[B]Using the JDK_JAVA_OPTIONS Launcher Environment Variable\f[R] مراجعه کنید.
.RE
.PP
به طور پیش‌فرض، نخستین آرگومانی که گزینه‌ای برای دستور \f[CR]java\f[R] نباشد، نام کامل (fully qualified name) کلاسی است که باید فراخوانی شود.
اگر \f[CR]\-jar\f[R] مشخص شده باشد، آرگومان آن نام فایل JAR حاوی کلاس‌ها و فایل‌های منبع (resource) برای برنامه است.
کلاس آغازین باید توسط هدر مانیفست \f[CR]Main\-Class\f[R] در فایل مانیفست آن مشخص شده باشد.
.PP
آرگومان‌های پس از نام فایل کلاس یا نام فایل JAR به متد \f[CR]main()\f[R] ارسال می‌شوند..SS \f[CR]javaw\f[R]
\f[B]ویندوز:\f[R] دستور \f[CR]javaw\f[R] کاملاً مشابه \f[CR]java\f[R] است، با این تفاوت که با \f[CR]javaw\f[R] هیچ پنجرهٔ کنسول مرتبطی باز نمی‌شود.
زمانی از \f[CR]javaw\f[R] استفاده کنید که نمی‌خواهید پنجرهٔ خط فرمان ظاهر شود.
با این حال، در صورت شکست در راه‌اندازی، اجراکنندهٔ \f[CR]javaw\f[R] کادر محاوره‌ای حاوی اطلاعات خطا نمایش خواهد داد.
.SH "استفاده از حالت فایل منبع برای اجرای برنامه‌های کد منبع (USING SOURCE\-FILE MODE TO LAUNCH SOURCE\-CODE PROGRAMS)"
برای راه‌اندازی کلاسی که در یک فایل منبع تعریف شده است، اجراکنندهٔ \f[CR]java\f[R] را در حالت فایل منبع (source\-file mode) اجرا کنید.
ورود به حالت فایل منبع توسط دو مورد در خط فرمان \f[CR]java\f[R] تعیین می‌شود:
.IP \(bu 2
نخستین مورد در خط فرمان که گزینه یا بخشی از یک گزینه نیست.
به عبارت دیگر، موردی در خط فرمان که در غیر این صورت نام کلاس اصلی (main class) می‌بود.
.IP \(bu 2
گزینهٔ \f[CR]\-\-source\f[R] \f[I]version\f[R]، در صورت وجود.
.PP
اگر کلاس به یک فایل موجود اشاره کند که دارای پسوند \f[CR].java\f[R] است، یا اگر گزینهٔ \f[CR]\-\-source\f[R] مشخص شده باشد، حالت فایل منبع انتخاب می‌شود.
سپس فایل منبع کامپایل و اجرا می‌گردد.
گزینهٔ \f[CR]\-\-source\f[R] می‌تواند برای تعیین نسخهٔ منبع (\f[I]version\f[R]) یا \f[I]N\f[R] کد منبع استفاده شود.
این مقدار، API قابل استفاده را تعیین می‌کند.
هنگامی که \f[CR]\-\-source\f[R] \f[I]N\f[R] را مشخص می‌کنید، تنها می‌توانید از API عمومی‌ای که در JDK \f[I]N\f[R] تعریف شده است استفاده نمایید.
.RS
.PP
\f[B]نکته:\f[R] مقادیر معتبر \f[I]N\f[R] برای هر نسخه تغییر می‌کند و مقادیر جدید اضافه و مقادیر قدیمی حذف می‌شوند.
اگر از مقداری برای \f[I]N\f[R] استفاده کنید که دیگر پشتیبانی نمی‌شود، پیام خطا دریافت خواهید کرد.
مقادیر پشتیبانی‌شده برای \f[I]N\f[R] عبارتند از انتشار کنونی Java SE (\f[CR]26\f[R]) و تعداد محدودی از نسخه‌های پیشین، که جزئیات آن‌ها در راهنمای خط فرمان \f[CR]javac\f[R]، ذیل گزینه‌های \f[CR]\-\-source\f[R] و \f[CR]\-\-release\f[R] آمده است.
.RE
.PP
اگر فایل دارای پسوند \f[CR].java\f[R] نباشد، باید از گزینهٔ \f[CR]\-\-source\f[R] استفاده شود تا به دستور \f[CR]java\f[R] اعلام کند از حالت فایل منبع استفاده کند.
گزینهٔ \f[CR]\-\-source\f[R] برای مواردی به کار می‌رود که فایل منبع یک \(dqاسکریپت\(dq برای اجراست و نام فایل منبع از قواعد نام‌گذاری معمول فایل‌های منبع Java پیروی نمی‌کند.
.PP
در حالت فایل منبع، عملکرد به گونه‌ای است که گویی فایل منبع درون حافظه کامپایل شده و نخستین کلاس یافت‌شده در فایل منبع اجرا می‌شود.
هر آرگومانی که در خط فرمان اصلی پس از نام فایل منبع قرار گیرد، هنگام اجرا به کلاس کامپایل‌شده ارسال می‌شود.
.PP
برای نمونه، اگر فایلی با نام \f[CR]HelloWorld.java\f[R] وجود داشته باشد و شامل کلاسی به نام \f[CR]HelloWorld\f[R] باشد، دستور حالت فایل منبع برای راه‌اندازی کلاس به صورت زیر خواهد بود:
.RS
.PP
\f[CR]java HelloWorld.java\f[R]
.RE
.PP
این شیوهٔ استفاده از حالت فایل منبع به طور غیررسمی معادل استفاده از دو دستور زیر است:
.IP
.EX
javac \-d <memory> \-\-source\-path <source\-root> HelloWorld.java
java \-\-class\-path <memory> HelloWorld
.EE
.PP
که در آن \f[CR]<source\-root>\f[R] محاسبه می‌شود
.PP
\f[B]در حالت فایل منبع، هرگونه گزینهٔ اضافی خط فرمان به صورت زیر پردازش می‌شود:\f[R]
.IP \(bu 2
راه‌انداز گزینه‌های مشخص‌شده پیش از فایل منبع را برای یافتن موارد مرتبط با کامپایل فایل منبع بررسی می‌کند.
.RS 2
.PP
این موارد شامل این گزینه‌ها و شکل‌های مختلف آن‌هاست: \f[CR]\-\-class\-path\f[R]، \f[CR]\-\-module\-path\f[R]،
\f[CR]\-\-add\-exports\f[R]، \f[CR]\-\-add\-modules\f[R]،
\f[CR]\-\-limit\-modules\f[R]، \f[CR]\-\-patch\-module\f[R]،
\f[CR]\-\-upgrade\-module\-path\f[R].
همچنین شامل گزینهٔ جدید \f[CR]\-\-enable\-preview\f[R] می‌شود که در JEP 12 شرح داده شده است.
.RE
.IP \(bu 2
هیچ تمهیدی برای ارسال گزینه‌های اضافی دیگر به کامپایلر، مانند \f[CR]\-processor\f[R] یا \f[CR]\-Werror\f[R]، در نظر گرفته نشده است.
.IP \(bu 2
فایل‌های آرگومان خط فرمان (فایل‌های \f[CR]\(at\f[R]) را می‌توان به شیوهٔ استاندارد استفاده کرد.
فهرست‌های طولانی از آرگومان‌ها چه برای VM یا برای برنامه‌ای که فراخوانی می‌شود، می‌توانند درون فایل‌هایی قرار گیرند که با افزودن نویسهٔ \f[CR]\(at\f[R] به ابتدای نام فایل در خط فرمان مشخص می‌شوند.
.PP
\f[B]در حالت فایل منبع، کامپایل به صورت زیر پیش می‌رود:\f[R]
.IP \(bu 2
هرگونه گزینهٔ خط فرمان که به محیط کامپایل مربوط باشد در نظر گرفته می‌شود.
این موارد شامل این گزینه‌ها هستند:
\f[CR]\-\-class\-path\f[R]/\f[CR]\-classpath\f[R]/\f[CR]\-cp\f[R]،
\f[CR]\-\-module\-path\f[R]/\f[CR]\-p\f[R]، \f[CR]\-\-add\-exports\f[R]،
\f[CR]\-\-add\-modules\f[R]، \f[CR]\-\-limit\-modules\f[R]،
\f[CR]\-\-patch\-module\f[R]، \f[CR]\-\-upgrade\-module\-path\f[R]،
\f[CR]\-\-enable\-preview\f[R].
.IP \(bu 2
ریشهٔ درخت منبع، \f[CR]<source\-root>\f[R]، بر اساس پکیج کلاسی که راه‌اندازی می‌شود محاسبه می‌گردد.
برای نمونه، اگر \f[CR]HelloWorld.java\f[R] کلاس‌های خود را در پکیج \f[CR]hello\f[R] اعلان کرده باشد، انتظار می‌رود که فایل \f[CR]HelloWorld.java\f[R] در دایرکتوری \f[CR]somedir/hello/\f[R] قرار داشته باشد.
در این حالت، \f[CR]somedir\f[R] به عنوان ریشهٔ درخت منبع محاسبه می‌شود.
.IP \(bu 2
ریشهٔ درخت منبع به عنوان مسیر منبع (source\-path) برای کامپایل عمل می‌کند، تا سایر فایل‌های منبع موجود در آن درخت که مورد نیاز \f[CR]HelloWorld\f[R] هستند نیز بتوانند کامپایل شوند.
.IP \(bu 2
پردازش حاشیه‌نویسی‌ها (Annotation processing) غیرفعال است، درست مانند اینکه \f[CR]\-proc:none\f[R] اعمال شده باشد.
.IP \(bu 2
اگر نسخه‌ای از طریق گزینهٔ \f[CR]\-\-source\f[R] مشخص شده باشد، مقدار آن به عنوان آرگومان یک گزینهٔ ضمنی \f[CR]\-\-release\f[R] برای کامپایل استفاده می‌شود.
این کار هم نسخهٔ منبع پذیرفته‌شده توسط کامپایلر و هم API سیستمی را که کد موجود در فایل منبع می‌تواند استفاده کند تنظیم می‌کند.
.IP \(bu 2
اگر \f[CR]\-\-enable\-preview\f[R] مشخص شده باشد، می‌توان از آرگومان‌های \f[CR]\-\-source N\f[R] صرف‌نظر کرد.
اگر نسخهٔ زمان اجرای Java برابر با \f[CR]N\f[R] باشد، هنگام کامپایل فایل‌های منبع، \f[CR]\-\-release N\f[R] به صورت ضمنی اعمال می‌شود.
.IP \(bu 2
اگر فایلی به نام \f[CR]module\-info.java\f[R] در دایرکتوری \f[CR]<source\-root>\f[R] وجود داشته باشد، اعلان ماژول آن برای تعریف یک ماژول نام‌دار استفاده می‌شود که شامل تمام کلاس‌های کامپایل‌شده از فایل‌های \f[CR].java\f[R] در درخت منبع خواهد بود.
اگر \f[CR]module\-info.java\f[R] وجود نداشته باشد، تمام کلاس‌های کامپایل‌شده از فایل‌های منبع در بستر یک ماژول بی‌نام (unnamed module) کامپایل خواهند شد.
.IP \(bu 2
فایل منبعی که راه‌اندازی می‌شود باید شامل یک یا چند کلاس سطح‌بالا (top\-level) باشد که نخستین آن‌ها به عنوان کلاسی که باید اجرا شود در نظر گرفته می‌شود.
.IP \(bu 2
برای فایل منبعی که راه‌اندازی می‌شود، کامپایلر محدودیت اختیاری تعریف‌شده در انتهای JLS 7.6 را اعمال نمی‌کند؛ مبنی بر اینکه یک نوع (type) در یک پکیج نام‌دار باید در فایلی قرار داشته باشد که نام آن از نام آن نوع به‌همراه پسوند \f[CR].java\f[R] تشکیل شده است.
.IP \(bu 2
اگر یک فایل منبع دارای خطا باشد، پیام‌های خطای مناسب در جریان خطای استاندارد (standard error) نوشته می‌شوند و راه‌انداز با یک کد خروج غیرصفر خارج می‌شود.
.PP
\f[B]در حالت فایل منبع، اجرا به صورت زیر پیش می‌رود:\f[R]
.IP \(bu 2
کلاسی که باید اجرا شود نخستین کلاس سطح‌بالای یافت‌شده در فایل منبع است.
این کلاس باید حاوی اعلان یک متد ورودی \f[CR]main\f[R] باشد.
.IP \(bu 2
کلاس‌های کامپایل‌شده توسط یک بارگذار کلاس (class loader) سفارشی بارگذاری می‌شوند که کار را به بارگذار کلاس برنامه واگذار می‌کند.
این بدان معناست که کلاس‌های موجود در مسیر کلاس برنامه (application class path) نمی‌توانند به هیچ‌یک از کلاس‌های تعریف‌شده در فایل‌های منبع ارجاع دهند.
.IP \(bu 2
اگر فایل \f[CR]module\-info.java\f[R] در دایرکتوری \f[CR]<source\-root>\f[R] وجود داشته باشد، آن‌گاه تمام کلاس‌های کامپایل‌شده از فایل‌های \f[CR].java\f[R] در درخت منبع درون آن ماژول قرار خواهند گرفت، که به عنوان ماژول ریشه برای اجرای برنامه عمل خواهد کرد.
اگر \f[CR]module\-info.java\f[R] وجود نداشته باشد، کلاس‌های کامپایل‌شده در بستر یک ماژول بی‌نام اجرا می‌شوند، درست مانند اینکه \f[CR]\-\-add\-modules=ALL\-DEFAULT\f[R] اعمال شده باشد.
این امر علاوه بر هر گزینهٔ \f[CR]\-\-add\-module\f[R] دیگری است که ممکن است در خط فرمان مشخص شده باشد.
.IP \(bu 2
هر آرگومانی که در خط فرمان پس از نام فایل بیاید، به شیوهٔ معمول به متد \f[CR]main\f[R] ارسال می‌شود.
.IP \(bu 2
اگر در مسیر کلاس برنامه کلاسی با نام یکسان با کلاسی که باید اجرا شود وجود داشته باشد، یک خطا محسوب می‌شود..PP
برای جزئیات کامل، \f[B]JEP 458: Launch Multi\-File Source\-Code Programs\f[R]
[https://openjdk.org/jeps/458] را ببینید.
.SH "استفاده از متغیر محیطی اجراکننده JDK_JAVA_OPTIONS (USING THE JDK_JAVA_OPTIONS LAUNCHER ENVIRONMENT VARIABLE)"
متغیر محیطی \f[CR]JDK_JAVA_OPTIONS\f[R] محتوای خود را به ابتدای گزینه‌های تجزیه‌شده از خط فرمان پیوست (پیشوند) می‌کند.
محتوای متغیر محیطی \f[CR]JDK_JAVA_OPTIONS\f[R] فهرستی از آرگومان‌ها است که با نویسه‌های فاصله‌خالی (تعیین‌شده توسط \f[CR]isspace()\f[R]) از هم جدا شده‌اند.
این موارد به ابتدای آرگومان‌های خط فرمان فرستاده‌شده به اجراکنندهٔ \f[CR]java\f[R] اضافه می‌شوند.
الزامات کدگذاری برای این متغیر محیطی، مشابه خط فرمان \f[CR]java\f[R] در سیستم است.
با محتوای متغیر محیطی \f[CR]JDK_JAVA_OPTIONS\f[R] درست همانند مواردی که در خط فرمان مشخص می‌شوند رفتار می‌شود.
.PP
برای دربرگرفتن آرگومان‌هایی که حاوی نویسه‌های فاصله‌خالی هستند، می‌توان از نقل‌قول تکی (\f[CR]\(aq\f[R]) یا جفتی (\f[CR]\(dq\f[R]) استفاده کرد.
تمام محتوای بین نقل‌قول باز و نخستین نقل‌قول بستهٔ متناظر با آن، صرفاً با حذف جفت نقل‌قول حفظ می‌شود.
در صورتی که نقل‌قول منطبق پیدا نشود، اجراکننده با یک پیام خطا متوقف خواهد شد.
فایل‌های \f[CR]\(at\f[R] درست همان‌گونه که در خط فرمان تعیین می‌شوند، پشتیبانی می‌گردند.
هیچ نویسهٔ عمومی صریح (\f[CR]*\f[R]) در محتوای متغیر محیطی \f[CR]JDK_JAVA_OPTIONS\f[R] بسط داده نمی‌شود و همان‌گونه که هست به VM آغازین تحویل داده می‌شود.
به منظور کاهش سوءاستفاده‌های بالقوه از رفتار \f[CR]JDK_JAVA_OPTIONS\f[R]، گزینه‌هایی که کلاس اصلی را مشخص می‌کنند (مانند \f[CR]\-jar\f[R]) یا باعث می‌شوند اجراکنندهٔ \f[CR]java\f[R] بدون اجرای کلاس اصلی خارج شود (مانند \f[CR]\-h\f[R]) در متغیر محیطی مجاز نیستند.
اگر هر یک از این گزینه‌ها در متغیر محیطی ظاهر شوند، اجراکننده با یک پیام خطا متوقف می‌شود.
هنگامی که \f[CR]JDK_JAVA_OPTIONS\f[R] تنظیم شده باشد، اجراکننده پیامی را به عنوان یادآوری در stderr چاپ می‌کند.
.PP
\f[B]مثال:\f[R]
.IP
.EX
$ export JDK_JAVA_OPTIONS=\(aq\-g \(atfile1 \-Dprop=value \(atfile2 \-Dws.prop=\(dqwhite spaces\(dq\(aq
$ java \-Xint \(atfile3
.EE
.PP
معادل است با خط فرمان:
.IP
.EX
java \-g \(atfile1 \-Dprop=value \(atfile2 \-Dws.prop=\(dqwhite spaces\(dq \-Xint \(atfile3
.EE
.SH "مرور اجمالی گزینه‌های JAVA (OVERVIEW OF JAVA OPTIONS)"
دستور \f[CR]java\f[R] از طیف گسترده‌ای از گزینه‌ها در دسته‌بندی‌های زیر پشتیبانی می‌کند:
.IP \(bu 2
\f[B]گزینه‌های استاندارد Java\f[R]: گزینه‌هایی که پشتیبانی از آن‌ها توسط تمام پیاده‌سازی‌های ماشین مجازی جاوا (JVM) تضمین شده است.
این گزینه‌ها برای اقدامات معمول به کار می‌روند، مانند بررسی نسخهٔ JRE، تنظیم مسیر کلاس (class path)، فعال‌سازی خروجی پرگو (verbose) و غیره.
.IP \(bu 2
\f[B]گزینه‌های اضافی Java\f[R]: گزینه‌های عمومی که مختص ماشین مجازی Java HotSpot هستند.
پشتیبانی از آن‌ها در تمام پیاده‌سازی‌های JVM تضمین نشده است و در معرض تغییر هستند.
این گزینه‌ها با \f[CR]\-X\f[R] آغاز می‌شوند.
.PP
استفاده از گزینه‌های پیشرفته برای مصارف عادی توصیه نمی‌شود.
این‌ها گزینه‌های توسعه‌دهنده هستند که برای تنظیم بخش‌های خاصی از عملکرد ماشین مجازی Java HotSpot به کار می‌روند که اغلب نیازمندی‌های سیستمی خاصی داشته و ممکن است نیازمند دسترسی ویژه به پارامترهای پیکربندی سیستم باشند.
چندین نمونه از تنظیم کارایی در \f[B]Performance Tuning Examples\f[R] ارائه شده است.
پشتیبانی از این گزینه‌ها در تمامی پیاده‌سازی‌های JVM تضمین نشده است و در معرض تغییر هستند.
گزینه‌های پیشرفته با \f[CR]\-XX\f[R] آغاز می‌شوند.
.IP \(bu 2
\f[B]گزینه‌های پیشرفته زمان اجرا برای Java\f[R]: رفتار زمان اجرای Java HotSpot VM را کنترل می‌کنند.
.IP \(bu 2
\f[B]گزینه‌های پیشرفته کامپایلر JIT برای Java\f[R]: کامپایل پویای در زمان اجرا (JIT) انجام‌شده توسط Java HotSpot VM را کنترل می‌کنند.
.IP \(bu 2
\f[B]گزینه‌های پیشرفته قابلیت سرویس‌دهی برای Java\f[R]: امکان جمع‌آوری اطلاعات سیستم و انجام اشکال‌زدایی گسترده را فراهم می‌سازند.
.IP \(bu 2
\f[B]گزینه‌های پیشرفته بازیافت حافظه برای Java\f[R]: نحوهٔ اجرای فرایند بازیافت حافظه (GC) را توسط Java HotSpot کنترل می‌کنند.
.PP
گزینه‌های دودویی (Boolean) برای فعال‌کردن قابلیتی که به‌طور پیش‌فرض غیرفعال است یا غیرفعال‌کردن قابلیتی که به‌طور پیش‌فرض فعال است استفاده می‌شوند.
چنین گزینه‌هایی نیازی به پارامتر ندارند.
گزینه‌های بولی \f[CR]\-XX\f[R] با علامت مثبت (\f[CR]\-XX:+\f[R]\f[I]OptionName\f[R]) فعال و با علامت منفی (\f[CR]\-XX:\-\f[R]\f[I]OptionName\f[R]) غیرفعال می‌شوند.
.PP
برای گزینه‌هایی که نیاز به یک آرگومان دارند، آرگومان ممکن است با فاصله، دو‌نقطه (:) یا علامت مساوی (=) از نام گزینه جدا شود، یا ممکن است آرگومان مستقیماً پس از گزینه بیاید (نحو دقیق برای هر گزینه متفاوت است).
اگر از شما انتظار می‌رود اندازه را بر حسب بایت مشخص کنید، می‌توانید از هیچ پسوندی استفاده نکنید، یا از پسوند \f[CR]k\f[R] یا \f[CR]K\f[R] برای کیلوبایت (KB)، \f[CR]m\f[R] یا \f[CR]M\f[R] برای مگابایت (MB)، یا \f[CR]g\f[R] یا \f[CR]G\f[R] برای گیگابایت (GB) استفاده نمایید.
برای مثال، جهت تنظیم اندازه روی ۸ گیگابایت، می‌توانید یکی از مقادیر \f[CR]8g\f[R]، \f[CR]8192m\f[R]، \f[CR]8388608k\f[R] یا \f[CR]8589934592\f[R] را به عنوان آرگومان مشخص کنید.
اگر از شما خواسته شده است که درصد را تعیین کنید، از عددی بین ۰ تا ۱ استفاده کنید.
به عنوان مثال، برای ۲۵٪ مقدار \f[CR]0.25\f[R] را مشخص کنید.
.PP
بخش‌های زیر گزینه‌های منسوخ‌شده، متروک و حذف‌شده را شرح می‌دهند:
.IP \(bu 2
\f[B]گزینه‌های منسوخ‌شدهٔ Java\f[R]: پذیرفته می‌شوند و روی آن‌ها عمل می‌شود \-\-\- هنگام استفاده از آن‌ها یک هشدار صادر می‌گردد.
.IP \(bu 2
\f[B]گزینه‌های متروک Java\f[R]: پذیرفته می‌شوند اما نادیده گرفته می‌شوند \-\-\- هنگام استفاده از آن‌ها یک هشدار صادر می‌گردد.
.IP \(bu 2
\f[B]گزینه‌های حذف‌شدهٔ Java\f[R]: حذف شده‌اند \-\-\- استفاده از آن‌ها منجر به خطا می‌شود..SH "گزینه‌های استاندارد برای جاوا (STANDARD OPTIONS FOR JAVA)"
این‌ها پرکاربردترین گزینه‌هایی هستند که توسط تمامی پیاده‌سازی‌های JVM پشتیبانی می‌شوند.
.RS
.PP
\f[B]نکته:\f[R] برای مشخص کردن یک آرگومان برای یک گزینه بلند، می‌توانید از
\f[CR]\-\-\f[R]\f[I]name\f[R]\f[CR]=\f[R]\f[I]value\f[R] یا
\f[CR]\-\-\f[R]\f[I]name\f[R] \f[I]value\f[R] استفاده کنید.
.RE
.TP
\f[CR]\-agentlib:\f[R]\f[I]libname\f[R][\f[CR]=\f[R]\f[I]options\f[R]]
کتابخانه agent بومی (native) مشخص‌شده را بارگذاری می‌کند.
پس از نام کتابخانه، می‌توان از فهرستی از گزینه‌های مخصوص به آن کتابخانه که با کاما جدا شده‌اند استفاده کرد.
اگر گزینه \f[CR]\-agentlib:foo\f[R] مشخص شده باشد، JVM با استفاده از قراردادهای نام‌گذاری و مکان‌های خاص پلتفرم، تلاش می‌کند کتابخانه‌ای به نام \f[CR]foo\f[R] را بارگذاری کند:
.RS
.IP \(bu 2
\f[B]لینوکس و سایر پلتفرم‌های شبه‌پازیکس (POSIX\-like):\f[R] ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای با نام \f[CR]libfoo.so\f[R] را در مکان مشخص‌شده توسط متغیر سیستمی \f[CR]LD_LIBRARY_PATH\f[R] بارگذاری کند.
.IP \(bu 2
\f[B]سیستم‌عامل macOS:\f[R] ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای با نام \f[CR]libfoo.dylib\f[R] را در مکان مشخص‌شده توسط متغیر سیستمی \f[CR]DYLD_LIBRARY_PATH\f[R] بارگذاری کند.
.IP \(bu 2
\f[B]ویندوز:\f[R] ماشین مجازی JVM تلاش می‌کند کتابخانه‌ای با نام \f[CR]foo.dll\f[R] را در مکان مشخص‌شده توسط متغیر سیستمی \f[CR]PATH\f[R] بارگذاری کند.
.RS 2
.PP
مثال زیر نحوه بارگذاری کتابخانه Java Debug Wire Protocol (JDWP) و گوش دادن به اتصال سوکت روی پورت 8000 را نشان می‌دهد، که پیش از بارگذاری کلاس اصلی، JVM را متوقف (suspend) می‌کند:
.RS
.PP
\f[CR]\-agentlib:jdwp=transport=dt_socket,server=y,address=8000\f[R]
.RE
.RE
.RE
.TP
\f[CR]\-agentpath:\f[R]\f[I]pathname\f[R][\f[CR]=\f[R]\f[I]options\f[R]]
کتابخانه agent بومی مشخص‌شده با نام مسیر مطلق را بارگذاری می‌کند.
این گزینه معادل \f[CR]\-agentlib\f[R] است، اما از مسیر کامل و نام فایل کتابخانه استفاده می‌کند.
.TP
\f[CR]\-\-class\-path\f[R] \f[I]classpath\f[R]، \f[CR]\-classpath\f[R] \f[I]classpath\f[R]، یا \f[CR]\-cp\f[R] \f[I]classpath\f[R]
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را برای جستجوی فایل‌های کلاس مشخص می‌کند.
.RS
در ویندوز، نقطه\-ویرگول (\f[CR];\f[R]) موجودیت‌ها را در این فهرست جدا می‌کند؛ در سایر پلتفرم‌ها این کار با دونقطه (\f[CR]:\f[R]) انجام می‌شود.
مشخص کردن \f[I]classpath\f[R] بر هر مقداری از متغیر محیطی \f[CR]CLASSPATH\f[R] تقدم دارد.
اگر گزینه مسیر کلاس استفاده نشود و \f[I]classpath\f[R] تنظیم نشده باشد، مسیر کلاس کاربر شامل دایرکتوری جاری (.) خواهد بود.
به‌عنوان یک تسهیل ویژه، مؤلفه‌ای از مسیر کلاس که نام پایه آن یک ستاره (*) باشد، معادل مشخص کردن فهرستی از تمام فایل‌های درون دایرکتوری با پسوند \f[CR].jar\f[R] یا \f[CR].JAR\f[R] تلقی می‌شود.
یک برنامه جاوا تفاوتی بین این دو روش فراخوانی مشاهده نمی‌کند.
برای مثال، اگر دایرکتوری mydir شامل \f[CR]a.jar\f[R] و \f[CR]b.JAR\f[R] باشد، مؤلفه مسیر کلاس mydir/* به \f[CR]A.jar:b.JAR\f[R] بسط داده می‌شود، با این تفاوت که ترتیب فایل‌های JAR نامشخص است.
تمام فایل‌های \f[CR].jar\f[R] موجود در دایرکتوری مشخص‌شده، حتی موارد پنهان، در فهرست گنجانده می‌شوند.
یک مدخل مسیر کلاس متشکل از یک ستاره (*) به فهرستی از تمام فایل‌های jar در دایرکتوری جاری بسط می‌یابد.
متغیر محیطی \f[CR]CLASSPATH\f[R] نیز، در صورت تعریف، به‌طور مشابهی بسط می‌یابد.
هرگونه بسط نویسه‌های عام (wildcard) در مسیر کلاس پیش از آغاز به کار Java VM رخ می‌دهد.
برنامه‌های جاوا هرگز نویسه‌های عامی را که بسط نیافته‌اند مشاهده نمی‌کنند، مگر با پرس‌وجو از محیط، مانند فراخوانی \f[CR]System.getenv(\(dqCLASSPATH\(dq)\f[R].
.RE
.TP
\f[CR]\-\-disable\-\(atfiles\f[R]
می‌تواند در هر کجای خط فرمان، از جمله درون یک فایل آرگومان، استفاده شود تا از بسط بیشتر \f[CR]\(atfilename\f[R] جلوگیری کند.
این گزینه بسط فایل‌های آرگومان \f[CR]\(at\f[R]\-argfiles بعد از این گزینه را متوقف می‌کند.
.TP
\f[CR]\-\-enable\-preview\f[R]
به کلاس‌ها اجازه می‌دهد به \f[B]ویژگی‌های پیش‌نمایش (preview features)\f[R]
[https://docs.oracle.com/en/java/javase/12/language/index.html#JSLAN\-GUID\-5A82FE0E\-0CA4\-4F1F\-B075\-564874FE2823]
این نسخه وابسته باشند.
.TP
\f[CR]\-\-enable\-native\-access\f[R] \f[I]module\f[R][\f[CR],\f[R]\f[I]module\f[R]...]
دسترسی بومی (Native access) شامل دسترسی به کد یا داده‌های خارج از محیط زمان اجرای جاوا (Java runtime) است.
این کار عموماً ناامن است و در صورت اجرای نادرست ممکن است به کرش JVM یا خرابی حافظه منجر شود.
دسترسی بومی می‌تواند در نتیجه فراخوانی متدی رخ دهد که یا \f[B]محدودشده (restricted)\f[R] [https://openjdk.org/jeps/454#Safety] باشد، یا \f[CR]native\f[R].
این گزینه به کدهای موجود در ماژول‌های مشخص‌شده اجازه دسترسی بومی را می‌دهد.
دسترسی بومی رخ‌داده در ماژولی که صراحتاً فعال نشده باشد، \f[I]غیرمجاز (illegal)\f[R] تلقی می‌شود.
.RS
\f[I]module\f[R] می‌تواند نام یک ماژول، یا \f[CR]ALL\-UNNAMED\f[R] برای اشاره به کدهای موجود در مسیر کلاس باشد.
.RE
.TP
\-\f[CR]\-\-illegal\-native\-access=\f[R]\f[I]parameter\f[R]
این گزینه نحوه مدیریت دسترسی بومی غیرمجاز را مشخص می‌کند:
.RS
.RS
.PP
\f[B]نکته:\f[R] این گزینه در نسخه‌های آینده حذف خواهد شد.
.RE
.IP \(bu 2
\f[CR]allow\f[R]: این حالت اجازه دسترسی بومی غیرمجاز را در تمام ماژول‌ها، بدون انتشار هیچ هشداری می‌دهد.
.IP \(bu 2
\f[CR]warn\f[R]: این حالت مشابه \f[CR]allow\f[R] است، جز اینکه برای نخستین دسترسی بومی غیرمجاز مشاهده‌شده در یک ماژول، یک پیام هشدار صادر می‌شود.
این حالت در JDK فعلی پیش‌فرض است اما در نسخه‌های آینده تغییر خواهد کرد.
.IP \(bu 2
\f[CR]deny\f[R]: این حالت دسترسی بومی غیرمجاز را غیرفعال می‌کند.
بدین صورت که هر دسترسی بومی غیرمجاز موجب بروز یک \f[CR]IllegalCallerException\f[R] می‌شود.
این حالت در نسخه‌های آینده به عنوان پیش‌فرض در نظر گرفته خواهد شد.
برای اطمینان از آماده بودن برنامه خود برای نسخه‌های آینده JDK، آن را با \f[CR]\-\-illegal\-native\-access=deny\f[R] همراه با هر گزینه \f[CR]\-\-enable\-native\-access\f[R] لازم اجرا کنید.
.RE
.TP
\f[CR]\-\-enable\-final\-field\-mutation\f[R] \f[I]module\f[R][,\f[I]module\f[R]...]
تغییر دادن (Mutation) فیلدهای final از طریق reflection API در پلتفرم جاوا امکان‌پذیر است.
با این وجود، این کار ایمنی و کارایی را در تمام برنامه‌ها به خطر می‌اندازد.
این گزینه به کدهای موجود در ماژول‌های مشخص‌شده اجازه می‌دهد فیلدهای final را از طریق بازتاب تغییر دهند.
تلاش کدها در هر ماژول دیگری برای تغییر فیلدهای final از طریق بازتاب، \f[I]غیرمجاز (illegal)\f[R] محسوب می‌شود.
.RS
\f[I]module\f[R] می‌تواند نام یک ماژول در مسیر ماژول، یا \f[CR]ALL\-UNNAMED\f[R] برای اشاره به کدهای موجود در مسیر کلاس باشد.
.RE
.TP
\-\f[CR]\-\-illegal\-final\-field\-mutation=\f[R]\f[I]parameter\f[R]
این گزینه نحوه مدیریت تغییر \f[I]غیرمجاز\f[R] فیلدهای final را مشخص می‌کند:
.RS
.RS
.PP
\f[B]نکته:\f[R] این گزینه در نسخه‌های آینده حذف خواهد شد.
.RE
.IP \(bu 2
\f[CR]allow\f[R]: این حالت اجازه تغییر غیرمجاز فیلدهای final را در تمام ماژول‌ها، بدون انتشار هیچ هشداری می‌دهد.
.IP \(bu 2
\f[CR]warn\f[R]: این حالت مشابه \f[CR]allow\f[R] است، به جز اینکه برای نخستین تغییر غیرمجاز فیلد final صورت‌گرفته در یک ماژول، یک پیام هشدار صادر می‌شود.
این حالت در JDK فعلی پیش‌فرض است اما در نسخه‌های آینده تغییر خواهد کرد.
.IP \(bu 2
\f[CR]debug\f[R]: این حالت مشابه \f[CR]allow\f[R] است، با این تفاوت که برای هر تغییر غیرمجاز فیلد final، یک پیام هشدار و ردگیری پشته (stack trace) چاپ می‌شود.
.IP \(bu 2
\f[CR]deny\f[R]: این حالت تغییر فیلدهای final را غیرفعال می‌کند.
بدین صورت که هر دسترسی برای تغییر غیرمجاز فیلد final موجب بروز یک \f[CR]IllegalAccessException\f[R] می‌شود.
این حالت در نسخه‌های آینده به عنوان پیش‌فرض در نظر گرفته خواهد شد.
برای اطمینان از آماده بودن برنامه خود برای نسخه‌های آینده JDK، آن را با \f[CR]\-\-illegal\-final\-field\-mutation=deny\f[R] همراه با هر گزینه \f[CR]\-\-enable\-final\-field\-mutation\f[R] لازم اجرا کنید.
.RE
.TP
\f[CR]\-\-finalization=\f[R]\f[I]value\f[R]
انجام فرایند نهایی‌سازی (finalization) اشیاء را توسط JVM کنترل می‌کند.
مقادیر معتبر شامل \(dqenabled\(dq و \(dqdisabled\(dq هستند.
نهایی‌سازی به‌طور پیش‌فرض فعال است، بنابراین مقدار \(dqenabled\(dq هیچ اثری ندارد.
مقدار \(dqdisabled\(dq نهایی‌سازی را غیرفعال می‌کند تا هیچ نهایی‌سازی (finalizer) فراخوانی نشود..TP
\f[CR]\-\-module\-path\f[R] \f[I]modulepath\f[R]... یا \f[CR]\-p\f[R] \f[I]modulepath\f[R]
محل یافتن ماژول‌های برنامه را با فهرستی از عناصر مسیر مشخص می‌کند.
عناصر یک مسیر ماژول می‌توانند مسیر فایلی به یک ماژول یا دایرکتوری‌ای حاوی ماژول‌ها باشند.
هر ماژول یا یک JAR ماژولار است یا یک دایرکتوری ماژول بازشده (exploded\-module).
.RS
در Windows، نقطه\-ویرگول (\f[CR];\f[R]) عناصر مسیر را در این فهرست جدا می‌کند؛ در سایر پلتفرم‌ها این جداکننده دو‌نقطه (\f[CR]:\f[R]) است.
.RE
.TP
\f[CR]\-\-upgrade\-module\-path\f[R] \f[I]modulepath\f[R]...
محل یافتن ماژول‌های جایگزین برای ماژول‌های ارتقا‌پذیر در تصویر زمان اجرا (runtime image) را با فهرستی از عناصر مسیر مشخص می‌کند.
عناصر یک مسیر ماژول می‌توانند مسیر فایلی به یک ماژول یا دایرکتوری‌ای حاوی ماژول‌ها باشند.
هر ماژول یا یک JAR ماژولار است یا یک دایرکتوری ماژول بازشده (exploded\-module).
.RS
در Windows، نقطه\-ویرگول (\f[CR];\f[R]) عناصر مسیر را در این فهرست جدا می‌کند؛ در سایر پلتفرم‌ها این جداکننده دو‌نقطه (\f[CR]:\f[R]) است.
.RE
.TP
\f[CR]\-\-add\-modules\f[R] \f[I]module\f[R][\f[CR],\f[R]\f[I]module\f[R]...]
علاوه بر ماژول اولیه، ماژول‌های ریشه را برای رفع وابستگی مشخص می‌کند.
\f[I]module\f[R] همچنین می‌تواند \f[CR]ALL\-DEFAULT\f[R]، \f[CR]ALL\-SYSTEM\f[R] و \f[CR]ALL\-MODULE\-PATH\f[R] باشد.
.TP
\f[CR]\-\-list\-modules\f[R]
ماژول‌های قابل‌مشاهده را فهرست کرده و سپس خارج می‌شود.
.TP
\f[CR]\-d\f[R] \f[I]module_name\f[R] یا \f[CR]\-\-describe\-module\f[R] \f[I]module_name\f[R]
یک ماژول مشخص‌شده را توصیف کرده و سپس خارج می‌شود.
.TP
\f[CR]\-\-dry\-run\f[R]
ماشین مجازی (VM) را ایجاد می‌کند اما متد اصلی (main) را اجرا نمی‌کند.
این گزینهٔ \f[CR]\-\-dry\-run\f[R] می‌تواند برای اعتبارسنجی گزینه‌های خط فرمان مانند پیکربندی سیستم ماژول مفید باشد.
.TP
\f[CR]\-\-validate\-modules\f[R]
تمام ماژول‌ها را اعتبارسنجی کرده و خارج می‌شود.
این گزینه برای یافتن تداخل‌ها و سایر خطاهای ماژول‌های موجود در مسیر ماژول مفید است.
.TP
\f[CR]\-D\f[R]\f[I]property\f[R]\f[CR]=\f[R]\f[I]value\f[R]
مقدار یک ویژگی سیستمی را تنظیم می‌کند.
متغیر \f[I]property\f[R] رشته‌ای بدون فاصله است که نام ویژگی را نشان می‌دهد.
متغیر \f[I]value\f[R] رشته‌ای است که مقدار ویژگی را نشان می‌دهد.
اگر \f[I]value\f[R] رشته‌ای حاوی فاصله است، آن را داخل علامت نقل‌قول قرار دهید (برای مثال \f[CR]\-Dfoo=\(dqfoo bar\(dq\f[R]).
.TP
\f[CR]\-disableassertions\f[R][\f[CR]:\f[R][\f[I]packagename\f[R]]...|\f[CR]:\f[R]\f[I]classname\f[R]] یا \f[CR]\-da\f[R][\f[CR]:\f[R][\f[I]packagename\f[R]]...|\f[CR]:\f[R]\f[I]classname\f[R]]
گزاره‌های شرطی بررسی صحت (assertions) را غیرفعال می‌کند.
به‌طور پیش‌فرض، assertionها در همهٔ بسته‌ها و کلاس‌ها غیرفعال هستند.
بدون آرگومان، \f[CR]\-disableassertions\f[R] (\f[CR]\-da\f[R]) assertionها را در تمام بسته‌ها و کلاس‌ها غیرفعال می‌کند.
با آرگومان \f[I]packagename\f[R] که به \f[CR]...\f[R] ختم می‌شود، این سوییچ assertionها را در بستهٔ مشخص‌شده و تمامی زیربسته‌های آن غیرفعال می‌کند.
اگر آرگومان صرفاً \f[CR]...\f[R] باشد، سوییچ assertionها را در بستهٔ بی‌نام در دایرکتوری کاری فعلی غیرفعال می‌کند.
با آرگومان \f[I]classname\f[R]، این سوییچ assertionها را در کلاس مشخص‌شده غیرفعال می‌کند.
.RS
گزینهٔ \f[CR]\-disableassertions\f[R] (\f[CR]\-da\f[R]) بر تمامی بارگذارهای کلاس و کلاس‌های سیستمی (که بارگذار کلاس ندارند) اعمال می‌شود.
یک استثنا برای این قاعده وجود دارد: اگر این گزینه بدون هیچ آرگومانی ارائه شود، بر کلاس‌های سیستمی اعمال نخواهد شد.
این امر غیرفعال کردن assertionها را در تمام کلاس‌ها به‌جز کلاس‌های سیستمی آسان می‌کند.
گزینهٔ \f[CR]\-disablesystemassertions\f[R] به شما امکان می‌دهد تا assertionها را در تمام کلاس‌های سیستمی غیرفعال کنید.
جهت فعال‌سازی صریح assertionها در بسته‌ها یا کلاس‌های مشخص، از گزینهٔ \f[CR]\-enableassertions\f[R] (\f[CR]\-ea\f[R]) استفاده کنید.
هر دو گزینه می‌توانند به‌طور هم‌زمان استفاده شوند.
برای مثال، جهت اجرای برنامهٔ \f[CR]MyClass\f[R] با assertionهای فعال در بستهٔ \f[CR]com.wombat.fruitbat\f[R] (و هر یک از زیربسته‌های آن) اما غیرفعال در کلاس \f[CR]com.wombat.fruitbat.Brickbat\f[R]، از دستور زیر استفاده کنید:
.RS
.PP
\f[CR]java \-ea:com.wombat.fruitbat... \-da:com.wombat.fruitbat.Brickbat MyClass\f[R]
.RE
.RE
.TP
\f[CR]\-disablesystemassertions\f[R] یا \f[CR]\-dsa\f[R]
assertionها را در تمام کلاس‌های سیستمی غیرفعال می‌کند.
.TP
\f[CR]\-enableassertions\f[R][\f[CR]:\f[R][\f[I]packagename\f[R]]...|\f[CR]:\f[R]\f[I]classname\f[R]] یا \f[CR]\-ea\f[R][\f[CR]:\f[R][\f[I]packagename\f[R]]...|\f[CR]:\f[R]\f[I]classname\f[R]]
گزاره‌های شرطی بررسی صحت (assertions) را فعال می‌کند.
به‌طور پیش‌فرض، assertionها در همهٔ بسته‌ها و کلاس‌ها غیرفعال هستند.
بدون آرگومان، \f[CR]\-enableassertions\f[R] (\f[CR]\-ea\f[R]) assertionها را در تمام بسته‌ها و کلاس‌ها فعال می‌کند.
با آرگومان \f[I]packagename\f[R] که به \f[CR]...\f[R] ختم می‌شود، این سوییچ assertionها را در بستهٔ مشخص‌شده و تمامی زیربسته‌های آن فعال می‌کند.
اگر آرگومان صرفاً \f[CR]...\f[R] باشد، سوییچ assertionها را در بستهٔ بی‌نام در دایرکتوری کاری فعلی فعال می‌کند.
با آرگومان \f[I]classname\f[R]، این سوییچ assertionها را در کلاس مشخص‌شده فعال می‌کند.
.RS
گزینهٔ \f[CR]\-enableassertions\f[R] (\f[CR]\-ea\f[R]) بر تمامی بارگذارهای کلاس و کلاس‌های سیستمی (که بارگذار کلاس ندارند) اعمال می‌شود.
یک استثنا برای این قاعده وجود دارد: اگر این گزینه بدون هیچ آرگومانی ارائه شود، بر کلاس‌های سیستمی اعمال نخواهد شد.
این امر فعال کردن assertionها را در تمام کلاس‌ها به‌جز کلاس‌های سیستمی آسان می‌کند.
گزینهٔ \f[CR]\-enablesystemassertions\f[R] سوییچ مجزایی برای فعال کردن assertionها در تمام کلاس‌های سیستمی فراهم می‌کند.
جهت غیرفعال‌سازی صریح assertionها در بسته‌ها یا کلاس‌های مشخص، از گزینهٔ \f[CR]\-disableassertions\f[R] (\f[CR]\-da\f[R]) استفاده کنید.
اگر یک دستور واحد شامل چندین نمونه از این سوییچ‌ها باشد، آن‌ها به ترتیب، قبل از بارگذاری هر کلاسی پردازش می‌شوند.
برای مثال، جهت اجرای برنامهٔ \f[CR]MyClass\f[R] در حالی که assertionها فقط در بستهٔ \f[CR]com.wombat.fruitbat\f[R] (و هر یک از زیربسته‌های آن) فعال بوده اما در کلاس \f[CR]com.wombat.fruitbat.Brickbat\f[R] غیرفعال باشند، از دستور زیر استفاده کنید:
.RS
.PP
\f[CR]java \-ea:com.wombat.fruitbat... \-da:com.wombat.fruitbat.Brickbat MyClass\f[R]
.RE
.RE
.TP
\f[CR]\-enablesystemassertions\f[R] یا \f[CR]\-esa\f[R]
assertionها را در تمام کلاس‌های سیستمی فعال می‌کند.
.TP
\f[CR]\-help\f[R]، \f[CR]\-h\f[R] یا \f[CR]\-?\f[R]
پیام راهنما را در جریان خطا چاپ می‌کند.
.TP
\f[CR]\-\-help\f[R]
پیام راهنما را در جریان خروجی چاپ می‌کند.
.TP
\f[CR]\-javaagent:\f[R]\f[I]jarpath\f[R][\f[CR]=\f[R]\f[I]options\f[R]]
عامل (agent) مشخص‌شدهٔ زبان برنامه‌نویسی Java را بارگذاری می‌کند.
ببینید: \f[CR]java.lang.instrument\f[R].
.TP
\f[CR]\-\-show\-version\f[R]
نسخهٔ محصول را در جریان خروجی چاپ کرده و ادامه می‌دهد.
.TP
\f[CR]\-showversion\f[R]
نسخهٔ محصول را در جریان خطا چاپ کرده و ادامه می‌دهد.
.TP
\f[CR]\-\-show\-module\-resolution\f[R]
خروجی رفع وابستگی ماژول را در حین راه‌اندازی نمایش می‌دهد.
.TP
\f[CR]\-splash:\f[R]\f[I]imagepath\f[R]
صفحهٔ آغازین (splash screen) را با تصویر مشخص‌شده با \f[I]imagepath\f[R] نمایش می‌دهد.
تصاویر مقیاس‌بندی‌شدهٔ HiDPI به‌طور خودکار پشتیبانی شده و در صورت موجود بودن استفاده می‌شوند.
نام فایل تصویر بدون مقیاس، مانند \f[CR]image.ext\f[R]، باید همیشه به‌عنوان آرگومان به گزینهٔ \f[CR]\-splash\f[R] داده شود.
مناسب‌ترین تصویر مقیاس‌بندی‌شدهٔ ارائه‌شده به‌طور خودکار انتخاب می‌شود.
.RS
برای مثال، جهت نمایش فایل \f[CR]splash.gif\f[R] از دایرکتوری \f[CR]images\f[R] هنگام شروع برنامه‌تان، از گزینهٔ زیر استفاده کنید:
.RS
.PP
\f[CR]\-splash:images/splash.gif\f[R]
.RE
برای اطلاعات بیشتر به مستندات SplashScreen API مراجعه کنید.
.RE
.TP
\f[CR]\-verbose:class\f[R]
اطلاعات مربوط به هر کلاس بارگذاری‌شده را نمایش می‌دهد.
.TP
\f[CR]\-verbose:gc\f[R]
اطلاعات مربوط به هر رویداد جمع‌آوری زباله (GC) را نمایش می‌دهد.
.TP
\f[CR]\-verbose:jni\f[R]
اطلاعات مربوط به استفاده از متدهای native و سایر فعالیت‌های Java Native Interface (JNI) را نمایش می‌دهد.
.TP
\f[CR]\-verbose:module\f[R]
اطلاعات مربوط به ماژول‌های در حال استفاده را نمایش می‌دهد.
.TP
\f[CR]\-\-version\f[R]
نسخهٔ محصول را در جریان خروجی چاپ کرده و خارج می‌شود.
.TP
\f[CR]\-version\f[R]
نسخهٔ محصول را در جریان خطا چاپ کرده و خارج می‌شود..TP
\f[CR]\-X\f[R]
راهنمای گزینه‌های اضافی را در جریان خطا چاپ می‌کند.
.TP
\f[CR]\-\-help\-extra\f[R]
راهنمای گزینه‌های اضافی را در جریان خروجی چاپ می‌کند.
.TP
\f[CR]\(at\f[R]\f[I]argfile\f[R]
یک یا چند فایل آرگومان با پیشوند \f[CR]\(at\f[R] را مشخص می‌کند که توسط دستور \f[CR]java\f[R] استفاده می‌شوند.
بسیار معمول است که خط فرمان \f[CR]java\f[R] به دلیل فایل‌های \f[CR].jar\f[R] مورد نیاز در classpath بسیار طولانی باشد.
گزینهٔ \f[CR]\(at\f[R]\f[I]argfile\f[R] با توانمندسازی اجراکننده برای بسط دادن محتویات فایل‌های آرگومان پس از بسط پوسته (shell expansion) اما پیش از پردازش آرگومان‌ها، بر محدودیت‌های طول خط فرمان غلبه می‌کند.
محتویات درون فایل‌های آرگومان بسط می‌یابند، زیرا در غیر این صورت، تا زمانی که گزینهٔ \f[CR]\-\-disable\-\(atfiles\f[R] دیده نشود، در خط فرمان تعیین می‌شدند.
.RS
فایل‌های آرگومان همچنین می‌توانند شامل نام کلاس اصلی و تمامی گزینه‌ها باشند.
اگر یک فایل آرگومان شامل تمام گزینه‌های مورد نیاز دستور \f[CR]java\f[R] باشد، خط فرمان می‌تواند به سادگی به شکل زیر باشد:
.RS
.PP
\f[CR]java \(at\f[R]\f[I]argfile\f[R]
.RE
برای توضیحات و مثال‌های استفاده از \f[CR]\(at\f[R]\-argfiles، بخش \f[B]java Command\-Line Argument Files\f[R] را ببینید.
.RE
.SH "گزینه‌های اضافی برای جاوا (EXTRA OPTIONS FOR JAVA)"
گزینه‌های زیر در \f[CR]java\f[R]، گزینه‌های عمومی هستند که مختص ماشین مجازی Java HotSpot می‌باشند.
.TP
\f[CR]\-Xbatch\f[R]
کامپایل در پس‌زمینه را غیرفعال می‌کند.
به‌طور پیش‌فرض، JVM متد را به عنوان یک وظیفه در پس‌زمینه کامپایل می‌کند و تا زمان اتمام کامپایل در پس‌زمینه، متد را در حالت مفسر اجرا می‌نماید.
پرچم \f[CR]\-Xbatch\f[R] کامپایل پس‌زمینه را غیرفعال می‌کند تا کامپایل تمام متدها به عنوان وظیفه‌ای در پیش‌زمینه تا زمان تکمیل ادامه یابد.
این گزینه معادل با \f[CR]\-XX:\-BackgroundCompilation\f[R] است.
.TP
\f[CR]\-Xbootclasspath/a:\f[R]\f[I]directories\f[R]|\f[I]zip\f[R]|\f[I]JAR\-files\f[R]
فهرستی از دایرکتوری‌ها، فایل‌های JAR و آرشیوهای ZIP را جهت الحاق به انتهای مسیر کلاس راه‌اندازی پیش‌فرض (bootstrap class path) مشخص می‌کند.
.RS
در ویندوز، نقطه ویرگول (\f[CR];\f[R]) موجودیت‌ها را در این فهرست جدا می‌کند؛ در سایر سیستم‌عامل‌ها این کار با دونقطه (\f[CR]:\f[R]) انجام می‌شود.
.RE
.TP
\f[CR]\-Xcheck:jni\f[R]
بررسی‌های اضافی را برای توابع واسط بومی جاوا (JNI) انجام می‌دهد.
.RS
بررسی‌های زیر نشان‌دهندهٔ مشکلات اساسی در کد بومی (native) تلقی می‌شوند و در چنین مواردی JVM با یک خطای غیرقابل جبران به کار خود پایان می‌دهد:
.IP \(bu 2
نخی (thread) که فراخوانی را انجام می‌دهد به JVM متصل نشده باشد.
.IP \(bu 2
نخی که فراخوانی را انجام می‌دهد از \f[CR]JNIEnv\f[R] متعلق به نخ دیگری استفاده کند.
.IP \(bu 2
یک بررسی اعتبارسنجی پارامتر با شکست مواجه شود:
.RS 2
.IP \(bu 2
یک \f[CR]jfieldID\f[R] یا \f[CR]jmethodID\f[R] نامعتبر تشخیص داده شود.
به عنوان مثال:
.RS 2
.IP \(bu 2
از نوع نادرست باشد
.IP \(bu 2
به کلاس نادرستی مرتبط شده باشد
.RE
.IP \(bu 2
پارامتری با نوع نادرست تشخیص داده شود.
.IP \(bu 2
مقدار نامعتبری برای یک پارامتر تشخیص داده شود.
به عنوان مثال:
.RS 2
.IP \(bu 2
مقدار \f[CR]NULL\f[R] در جایی که مجاز نیست
.IP \(bu 2
اندیس خارج از محدودهٔ آرایه، یا ظرفیت فریم
.IP \(bu 2
یک رشتهٔ غیر \f[CR]UTF\-8\f[R]
.IP \(bu 2
یک ارجاع نامعتبر JNI
.IP \(bu 2
تلاش برای استفاده از یک تابع \f[CR]ReleaseXXX\f[R] روی پارامتری که توسط تابع متناظر \f[CR]GetXXX\f[R] تولید نشده است
.RE
.RE
بررسی‌های زیر تنها منجر به چاپ هشدار می‌شوند:
.IP \(bu 2
یک فراخوانی JNI بدون بررسی استثنای معلق از فراخوانی قبلی JNI انجام شده باشد، در حالی که فراخوانی فعلی هنگام وجود استثنای معلق ایمن نیست.
.IP \(bu 2
یک توصیف‌گر کلاس در قالب تزیین‌شده (\f[CR]Lname;\f[R]) باشد، در حالی که نباید باشد.
.IP \(bu 2
پارامتر \f[CR]NULL\f[R] مجاز است، اما استفاده از آن جای سؤال دارد.
.IP \(bu 2
فراخوانی سایر توابع JNI در محدودهٔ \f[CR]Get/ReleasePrimitiveArrayCritical\f[R] یا \f[CR]Get/ReleaseStringCritical\f[R].
.IP \(bu 2
یک فراخوانی JNI برای تغییر دادن یک فیلد final انجام شده باشد.
هنگام استفاده از این گزینه، انتظار کاهش کارایی را داشته باشید.
.RE
.TP
\f[CR]\-Xcomp\f[R]
حالت آزمایشی برای به کار انداختن کامپایلرهای JIT.
این گزینه نباید در محیط‌های عملیاتی (production) استفاده شود.
.TP
\f[CR]\-Xdebug\f[R]
هیچ کاری انجام نمی‌دهد؛ برای حذف در انتشار‌های آینده منسوخ شده است.
.TP
\f[CR]\-Xdiag\f[R]
پیام‌های تشخیصی اضافی را نمایش می‌دهد.
.TP
\f[CR]\-Xint\f[R]
برنامه را فقط در حالت تفسیری اجرا می‌کند.
کامپایل به کد بومی غیرفعال شده و تمام بایت‌کد توسط مفسر اجرا می‌شود.
مزایای کارایی ارائه‌شده توسط کامپایلر درجا (JIT) در این حالت وجود ندارد.
.TP
\f[CR]\-Xinternalversion\f[R]
اطلاعات دقیق‌تری از نسخهٔ JVM را نسبت به گزینهٔ \f[CR]\-version\f[R] نمایش می‌دهد و سپس خارج می‌شود.
.TP
\f[CR]\-Xlog:\f[R]\f[I]option\f[R]
پیکربندی یا فعال‌سازی گزارش‌گیری با چارچوب گزارش‌گیری یکپارچهٔ ماشین مجازی جاوا (JVM).
بخش \f[B]Enable Logging with the JVM Unified Logging Framework\f[R] را ببینید.
.TP
\f[CR]\-Xmixed\f[R]
تمام بایت‌کد را توسط مفسر اجرا می‌کند، به جز متدهای پرکاربرد (hot methods) که به کد بومی کامپایل می‌شوند.
به‌طور پیش‌فرض فعال است.
برای غیرفعال کردن از \f[CR]\-Xint\f[R] استفاده کنید.
.TP
\f[CR]\-Xmn\f[R] \f[I]size\f[R]
اندازهٔ اولیه و حداکثر اندازه (به بایت) هیپ را برای نسل جوان (nursery) در زباله‌روب‌های نسلی تنظیم می‌کند.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] برای مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] برای گیگابایت ضمیمه کنید.
ناحیهٔ نسل جوان از هیپ برای اشیاء جدید استفاده می‌شود.
فرایند GC در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد.
اگر اندازهٔ نسل جوان خیلی کوچک باشد، تعداد زیادی زباله‌روبی جزئی (minor GC) انجام می‌شود.
اگر اندازه بیش از حد بزرگ باشد، فقط زباله‌روبی‌های کامل (full GC) انجام می‌شوند که ممکن است زمان زیادی به طول بینجامند.
توصیه می‌شود که اندازهٔ نسل جوان را برای زباله‌روب G1 تنظیم نکنید، و برای سایر زباله‌روب‌ها، اندازهٔ آن را بیشتر از ۲۵٪ و کمتر از ۵۰٪ اندازهٔ کلی هیپ نگه دارید.
مثال‌های زیر نحوهٔ تنظیم اندازهٔ اولیه و حداکثر اندازهٔ نسل جوان را روی ۲۵۶ مگابایت با استفاده از واحدهای مختلف نشان می‌دهند:
.RS
.IP
.EX
\-Xmn256m
\-Xmn262144k
\-Xmn268435456
.EE
به جای استفاده از گزینهٔ \f[CR]\-Xmn\f[R] برای تنظیم هم‌زمان اندازهٔ اولیه و حداکثر اندازهٔ هیپ برای نسل جوان، می‌توانید از \f[CR]\-XX:NewSize\f[R] برای تنظیم اندازهٔ اولیه و از \f[CR]\-XX:MaxNewSize\f[R] برای تنظیم حداکثر اندازه استفاده کنید.
.RE
.TP
\f[CR]\-Xms\f[R] \f[I]size\f[R]
حداقل و اندازهٔ اولیهٔ هیپ (به بایت) را تنظیم می‌کند.
این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۱ مگابایت باشد.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] برای مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] برای گیگابایت ضمیمه کنید.
مثال‌های زیر نحوهٔ تنظیم اندازهٔ حافظهٔ تخصیص‌یافته را روی ۶ مگابایت با استفاده از واحدهای مختلف نشان می‌دهند:
.RS.IP
.EX
\-Xms6291456
\-Xms6144k
\-Xms6m
.EE
اگر این گزینه را تنظیم نکنید، اندازه اولیه برابر با مجموع اندازه‌های تخصیص‌یافته به نسل قدیم (old generation) و نسل جوان (young generation) تعیین می‌شود.
اندازه اولیه هیپ برای نسل جوان را می‌توان با استفاده از گزینه \f[CR]\-Xmn\f[R] یا گزینه \f[CR]\-XX:NewSize\f[R] تنظیم کرد.
توجه داشته باشید که از گزینه \f[CR]\-XX:InitialHeapSize\f[R] نیز می‌توان برای تنظیم اندازه اولیه هیپ استفاده کرد.
اگر این گزینه پس از \f[CR]\-Xms\f[R] در خط فرمان بیاید، اندازه اولیه هیپ روی مقدار مشخص‌شده با \f[CR]\-XX:InitialHeapSize\f[R] تنظیم می‌شود.
.RE
.TP
\f[CR]\-Xmx\f[R] \f[I]size\f[R]
حداکثر اندازه (به بایت) هیپ را مشخص می‌کند.
این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۲ مگابایت باشد.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] را برای گیگابایت اضافه کنید.
مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود.
برای استقرار در محیط‌های سرور، معمولاً \f[CR]\-Xms\f[R] و \f[CR]\-Xmx\f[R] روی مقدار یکسانی تنظیم می‌شوند.
مثال‌های زیر نحوه تعیین حداکثر اندازه مجاز حافظه تخصیص‌یافته به ۸۰ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:
.RS
.IP
.EX
\-Xmx83886080
\-Xmx81920k
\-Xmx80m
.EE
گزینه \f[CR]\-Xmx\f[R] معادل \f[CR]\-XX:MaxHeapSize\f[R] است.
.RE
.TP
\f[CR]\-Xnoclassgc\f[R]
جمع‌آوری زباله (GC) مربوط به کلاس‌ها را غیرفعال می‌کند.
این کار می‌تواند در زمان GC صرفه‌جویی کرده و وقفه‌ها را در حین اجرای برنامه کاهش دهد.
هنگامی که \f[CR]\-Xnoclassgc\f[R] را هنگام راه‌اندازی مشخص می‌کنید، شیءهای کلاس (class objects) در برنامه در طول فرایند GC دست‌نخورده باقی می‌مانند و همواره زنده در نظر گرفته می‌شوند.
این امر می‌تواند به اشغال دائمی بخش بیشتری از حافظه منجر شود که در صورت عدم استفاده محتاطانه، موجب بروز استثنای کمبود حافظه (out\-of\-memory) خواهد شد.
.TP
\f[CR]\-Xrs\f[R]
استفاده از سیگنال‌های سیستم‌عامل توسط JVM را کاهش می‌دهد.
قلاب‌های خاموش‌سازی (shutdown hooks) امکان خروج منظم برنامه جاوا را با اجرای کد پاک‌سازی کاربر (مانند بستن اتصالات پایگاه داده) در هنگام خاموش‌سازی فراهم می‌کنند، حتی اگر JVM به طور ناگهانی خاتمه یابد.
.RS
.IP \(bu 2
\f[B]سیستم‌های غیر ویندوز (Non\-Windows):\f[R]
.RS 2
.IP \(bu 2
ماشین JVM سیگنال‌ها را به دام می‌اندازد تا قلاب‌های خاموش‌سازی را در شرایط خاتمه غیرمنتظره اجرا کند.
ماشین JVM از سیگنال‌های \f[CR]SIGHUP\f[R]، \f[CR]SIGINT\f[R] و \f[CR]SIGTERM\f[R] برای آغاز اجرای قلاب‌های خاموش‌سازی استفاده می‌کند.
.IP \(bu 2
برنامه‌هایی که JVM را درون خود تعبیه می‌کنند، معمولاً نیاز به رهگیری سیگنال‌هایی نظیر \f[CR]SIGINT\f[R] یا \f[CR]SIGTERM\f[R] دارند که می‌تواند منجر به تداخل با گرداننده‌های سیگنال (signal handlers) ماشین JVM شود.
گزینه \f[CR]\-Xrs\f[R] برای رفع این مسئله در نظر گرفته شده است.
هنگام استفاده از \f[CR]\-Xrs\f[R]، ماسک‌های سیگنال برای \f[CR]SIGINT\f[R]، \f[CR]SIGTERM\f[R]، \f[CR]SIGHUP\f[R] و \f[CR]SIGQUIT\f[R] توسط JVM تغییر داده نمی‌شوند و گرداننده‌ای برای این سیگنال‌ها نصب نمی‌گردد.
.RE
.IP \(bu 2
\f[B]ویندوز (Windows):\f[R]
.RS 2
.IP \(bu 2
ماشین JVM رویدادهای کنترلی کنسول را زیر نظر می‌گیرد تا قلاب‌های خاموش‌سازی را برای خاتمه‌های غیرمنتظره پیاده‌سازی کند.
به طور مشخص، JVM یک گرداننده کنترلی کنسول ثبت می‌کند که پردازش قلاب خاموش‌سازی را آغاز کرده و برای رویدادهای \f[CR]CTRL_C_EVENT\f[R]، \f[CR]CTRL_CLOSE_EVENT\f[R]، \f[CR]CTRL_LOGOFF_EVENT\f[R] و \f[CR]CTRL_SHUTDOWN_EVENT\f[R] مقدار \f[CR]TRUE\f[R] برمی‌گرداند.
.IP \(bu 2
ماشین JVM از سازوکار مشابهی برای پیاده‌سازی قابلیت تخلیه پشته ریسه‌ها (thread dumps) جهت مقاصد اشکال‌زدایی استفاده می‌کند.
ماشین JVM برای انجام تخلیه ریسه‌ها از \f[CR]CTRL_BREAK_EVENT\f[R] بهره می‌برد.
.IP \(bu 2
اگر JVM به عنوان یک سرویس اجرا شود (مثلاً به عنوان موتور سرولت برای یک وب‌سرور)، ممکن است \f[CR]CTRL_LOGOFF_EVENT\f[R] را دریافت کند، اما نباید فرایند خاموش‌سازی را آغاز نماید؛ زیرا سیستم‌عامل در واقع فرایند را خاتمه نمی‌دهد.
جهت اجتناب از تداخل‌های احتمالی نظیر این، می‌توان از گزینه \f[CR]\-Xrs\f[R] استفاده کرد.
هنگامی که گزینه \f[CR]\-Xrs\f[R] به کار می‌رود، JVM هیچ گرداننده کنترل کنسولی نصب نمی‌کند؛ بدین معنی که رویدادهای \f[CR]CTRL_C_EVENT\f[R]، \f[CR]CTRL_CLOSE_EVENT\f[R]، \f[CR]CTRL_LOGOFF_EVENT\f[R] یا \f[CR]CTRL_SHUTDOWN_EVENT\f[R] را زیر نظر نمی‌گیرد و پردازش نمی‌کند.
.RE
مشخص کردن \f[CR]\-Xrs\f[R] دو پیامد به همراه دارد:
.IP \(bu 2
\f[B]سیستم‌های غیر ویندوز (Non\-Windows):\f[R] تخلیه پشته ریسه با \f[CR]SIGQUIT\f[R] در دسترس نخواهد بود.
.IP \(bu 2
\f[B]ویندوز (Windows):\f[R] تخلیه پشته ریسه با Ctrl + Break در دسترس نخواهد بود.
اجرای قلاب‌های خاموش‌سازی بر عهده کد کاربر است، برای مثال از طریق فراخوانی \f[CR]System.exit()\f[R] در زمانی که قرار است JVM خاتمه یابد.
.RE
.TP
\f[CR]\-Xshare:\f[R]\f[I]mode\f[R]
حالت اشتراک‌گذاری داده‌های کلاس (CDS) را تنظیم می‌کند.
.RS
آرگومان‌های ممکن \f[I]mode\f[R] برای این گزینه عبارتند از:
.TP
\f[CR]auto\f[R]
استفاده از داده‌های کلاس مشترک در صورت امکان (پیش‌فرض).
.TP
\f[CR]on\f[R]
الزام در استفاده از داده‌های کلاس مشترک، در غیر این صورت با شکست مواجه می‌شود.
.RS
.PP
\f[B]توجه:\f[R] گزینه \f[CR]\-Xshare:on\f[R] فقط برای مقاصد آزمایشی استفاده می‌شود.
این گزینه در صورتی که بایگانی CDS قابل استفاده نباشد (مثلاً هنگام تغییر برخی پارامترهای مشخص VM، یا هنگام استفاده از یک JDK متفاوت)، ممکن است باعث خروج غیرمنتظره ماشین مجازی در هنگام راه‌اندازی شود.
این گزینه نباید در محیط‌های عملیاتی استفاده شود.
.RE
.TP
\f[CR]off\f[R]
هیچ تلاشی برای استفاده از داده‌های کلاس مشترک انجام نمی‌دهد.
.RE
.TP
\f[CR]\-XshowSettings\f[R]
همه تنظیمات را نمایش داده و سپس ادامه می‌دهد.
.TP
\f[CR]\-XshowSettings:\f[R]\f[I]category\f[R]
تنظیمات را نمایش داده و ادامه می‌دهد.
آرگومان‌های ممکن \f[I]category\f[R] برای این گزینه عبارتند از:
.RS
.TP
\f[CR]all\f[R]
تمام دسته‌های تنظیمات را با جزئیات کامل (\f[B]verbose\f[R]) نشان می‌دهد.
.TP
\f[CR]locale\f[R]
تنظیمات مربوط به محلی‌سازی (locale) را نمایش می‌دهد.
.TP
\f[CR]properties\f[R]
تنظیمات مربوط به ویژگی‌های سیستم (system properties) را نمایش می‌دهد.
.TP
\f[CR]security\f[R]
تمام تنظیمات مربوط به امنیت را نمایش می‌دهد.
.RS
آرگومان‌های زیردسته برای \f[CR]security\f[R] شامل موارد زیر است:
.IP \(bu 2
\f[CR]security:all\f[R] : تمام تنظیمات امنیتی را نشان می‌دهد
.IP \(bu 2
\f[CR]security:properties\f[R] : ویژگی‌های امنیتی را نشان می‌دهد
.IP \(bu 2
\f[CR]security:providers\f[R] : تنظیمات ارائه‌دهنده امنیتی ایستا را نشان می‌دهد
.IP \(bu 2
\f[CR]security:tls\f[R] : تنظیمات امنیتی مربوط به TLS را نشان می‌دهد
.RE
.TP
\f[CR]vm\f[R]
تنظیمات JVM را نمایش می‌دهد.
.TP
\f[CR]system\f[R]
\f[B]فقط در لینوکس:\f[R] پیکربندی سیستم میزبان یا کانتینر را نشان داده و ادامه می‌دهد.
.RE
.TP
\f[CR]\-Xss\f[R] \f[I]size\f[R]
اندازه پشته ریسه (thread stack) را (به بایت) تنظیم می‌کند.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] را برای گیگابایت اضافه کنید.
اندازه واقعی ممکن است بر اساس الزامات سیستم‌عامل، به مضربی از اندازه صفحه حافظه (page size) سیستم به سمت بالا گرد شود.
مقدار پیش‌فرض به بستر اجرایی (پلتفرم) بستگی دارد.
برای مثال:
.RS.IP \(bu 2
Linux/x64: 1024 KB
.IP \(bu 2
Linux/Aarch64: 2048 KB
.IP \(bu 2
macOS/x64: 1024 KB
.IP \(bu 2
macOS/Aarch64: 2048 KB
.IP \(bu 2
ویندوز: مقدار پیش‌فرض به حافظه مجازی بستگی دارد.
مثال‌های زیر اندازه پشته ریسه (thread stack) را در واحدهای مختلف روی 1024 KB تنظیم می‌کنند:
.IP
.EX
\-Xss1m
\-Xss1024k
\-Xss1048576
.EE
این گزینه مشابه \f[CR]\-XX:ThreadStackSize\f[R] است.
.RE
.TP
\f[CR]\-\-add\-reads\f[R] \f[I]module\f[R]\f[CR]=\f[R]\f[I]target\-module\f[R](\f[CR],\f[R]\f[I]target\-module\f[R])*
ماژول \f[I]module\f[R] را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، \f[I]target\-module\f[R] را بخواند.
\f[I]target\-module\f[R] می‌تواند برای خواندن تمام ماژول‌های بدون نام، برابر با \f[CR]ALL\-UNNAMED\f[R] باشد.
.TP
\f[CR]\-\-add\-exports\f[R] \f[I]module\f[R]\f[CR]/\f[R]\f[I]package\f[R]\f[CR]=\f[R]\f[I]target\-module\f[R](\f[CR],\f[R]\f[I]target\-module\f[R])*
ماژول \f[I]module\f[R] را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، پکیج \f[I]package\f[R] را به \f[I]target\-module\f[R] صادر (export) کند.
\f[I]target\-module\f[R] می‌تواند برای صادر کردن به تمام ماژول‌های بدون نام، برابر با \f[CR]ALL\-UNNAMED\f[R] باشد.
.TP
\f[CR]\-\-add\-opens\f[R] \f[I]module\f[R]\f[CR]/\f[R]\f[I]package\f[R]\f[CR]=\f[R]\f[I]target\-module\f[R](\f[CR],\f[R]\f[I]target\-module\f[R])*
ماژول \f[I]module\f[R] را به‌روزرسانی می‌کند تا بدون در نظر گرفتن اعلان ماژول، پکیج \f[I]package\f[R] را برای \f[I]target\-module\f[R] باز (open) کند.
.TP
\f[CR]\-\-limit\-modules\f[R] \f[I]module\f[R][\f[CR],\f[R]\f[I]module\f[R]...]
محدوده جهان ماژول‌های قابل مشاهده را تعیین می‌کند.
.TP
\f[CR]\-\-patch\-module\f[R] \f[I]module\f[R]\f[CR]=\f[R]\f[I]file\f[R](\f[CR];\f[R]\f[I]file\f[R])*
یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها بازنویسی یا تکمیل می‌کند.
.TP
\f[CR]\-\-source\f[R] \f[I]version\f[R]
نسخه مبدأ را در حالت source\-file تعیین می‌کند.
.TP
\f[CR]\-\-sun\-misc\-unsafe\-memory\-access=\f[R] \f[I]value\f[R]
استفاده از رابط برنامه‌نویسی (API) پشتیبانی‌نشده \f[CR]sun.misc.Unsafe\f[R] را مجاز یا رد می‌کند.
مقدار \f[I]value\f[R] یکی از موارد زیر است:
.RS
.TP
\f[CR]allow\f[R]
اجازه استفاده از متدهای دسترسی به حافظه را بدون هیچ هشداری در زمان اجرا می‌دهد.
.TP
\f[CR]warn\f[R]
اجازه استفاده از متدهای دسترسی به حافظه را می‌دهد، اما در اولین باری که هرگونه متد دسترسی به حافظه استفاده شود، یک هشدار صادر می‌کند.
حداکثر یک هشدار صادر خواهد شد.
.TP
\f[CR]debug\f[R]
اجازه استفاده از متدهای دسترسی به حافظه را می‌دهد، اما هنگام استفاده از هر متد دسترسی به حافظه، یک هشدار تک‌خطی و یک ردگیری پشته (stack trace) صادر می‌کند.
.TP
\f[CR]deny\f[R]
استفاده از متدهای دسترسی به حافظه را با پرتاب یک \f[CR]UnsupportedOperationException\f[R] در هر بار استفاده منع می‌کند.
مقدار پیش‌فرض در صورت مشخص نشدن گزینه، \f[CR]warn\f[R] است.
.RE
.SH "گزینه‌های اضافی برای MACOS (EXTRA OPTIONS FOR MACOS)"
گزینه‌های اضافی زیر مختص macOS هستند.
.TP
\f[CR]\-XstartOnFirstThread\f[R]
متد \f[CR]main()\f[R] را روی اولین ریسه (AppKit) اجرا می‌کند.
.TP
\f[CR]\-Xdock:name=\f[R]\f[I]application_name\f[R]
نام پیش‌فرض برنامه را که در داک (dock) نمایش داده می‌شود بازنویسی می‌کند.
.TP
\f[CR]\-Xdock:icon=\f[R]\f[I]path_to_icon_file\f[R]
آیکون پیش‌فرض نمایش داده شده در داک را بازنویسی می‌کند..SH "گزینه‌های پیشرفته برای جاوا (ADVANCED OPTIONS FOR JAVA)"
از این گزینه‌های \f[CR]java\f[R] می‌توان برای فعال‌سازی سایر گزینه‌های پیشرفته
استفاده کرد.
.TP
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R]
گزینه‌های در نظر گرفته شده برای عیب‌یابی JVM را فعال و باز می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و گزینه‌های عیب‌یابی در دسترس
نیستند.
.RS
گزینه‌های خط فرمانی که با استفاده از این گزینه فعال می‌شوند، پشتیبانی
نمی‌شوند.
اگر هنگام استفاده از هر یک از این گزینه‌ها با مشکلی مواجه شوید، بسیار
محتمل است که پیش از کمک پشتیبانی Oracle برای بررسی، از شما خواسته شود
مشکل را بدون استفاده از این گزینه‌های پشتیبانی‌نشده بازتولید کنید.
همچنین این احتمال وجود دارد که هر یک از این گزینه‌ها بدون هیچ‌گونه هشدار
قبلی حذف شوند یا رفتار آن‌ها تغییر کند.
.RE
.TP
\f[CR]\-XX:+UnlockExperimentalVMOptions\f[R]
گزینه‌هایی را که ویژگی‌های آزمایشی را در JVM ارائه می‌دهند، فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و ویژگی‌های آزمایشی در دسترس
نیستند.
.SH "گزینه‌های پیشرفته زمان اجرا برای جاوا (ADVANCED RUNTIME OPTIONS FOR JAVA)"
این گزینه‌های \f[CR]java\f[R] رفتار زمان اجرای Java HotSpot VM را کنترل
می‌کنند.
.TP
\f[CR]\-XX:ActiveProcessorCount=\f[R]\f[I]x\f[R]
تعداد پردازنده‌هایی (CPU) را که ماشین مجازی برای محاسبه اندازه استخرهای
ریسه (thread pools) جهت عملیات گوناگون مانند Garbage Collection و
ForkJoinPool استفاده می‌کند، رونویسی (override) می‌کند.
.RS
ماشین مجازی معمولاً تعداد پردازنده‌های دردسترس را از سیستم‌عامل به دست
می‌آورد.
این پرچم می‌تواند برای تقسیم‌بندی منابع CPU هنگام اجرای چندین فرایند جاوا
در کانتینرهای docker مفید باشد.
این پرچم حتی اگر \f[CR]UseContainerSupport\f[R] فعال نباشد نیز رعایت
می‌شود.
برای توضیحات مربوط به فعال‌سازی و غیرفعال‌سازی پشتیبانی از کانتینر،
\f[CR]\-XX:\-UseContainerSupport\f[R] را ببینید.
.RE
.TP
\f[CR]\-XX:AllocateHeapAt=\f[R]\f[I]path\f[R]
مسیری به سیستم‌فایل را دریافت کرده و از نگاشت حافظه (memory mapping) برای
تخصیص هیپ شیء (object heap) روی دستگاه حافظه استفاده می‌کند.
استفاده از این گزینه HotSpot VM را قادر می‌سازد تا هیپ شیء جاوا را روی
یک دستگاه حافظه جایگزین که توسط کاربر مشخص شده است، مانند NV\-DIMM،
تخصیص دهد.
.RS
دستگاه‌های حافظه جایگزینی که معناشناسی مشابهی با DRAM دارند، از جمله
معناشناسی عملیات اتمیک (atomic operations)، می‌توانند بدون نیاز به
تغییر کد برنامه موجود، به جای DRAM برای هیپ شیء به کار روند.
سایر ساختارهای حافظه (مانند code heap، metaspace و پشته‌های ریسه)
همچنان در DRAM مستقر خواهند ماند.
برخی از سیستم‌عامل‌ها حافظه‌های غیر DRAM را از طریق سیستم‌فایل ارائه
می‌دهند.
فایل‌های نگاشت‌شده به حافظه در این سیستم‌فایل‌ها، حافظه نهان صفحه
(page cache) را دور زده و یک نگاشت مستقیم از حافظه مجازی به حافظه
فیزیکی روی دستگاه فراهم می‌کنند.
پرچم‌های موجود مربوط به هیپ (مانند \f[CR]\-Xmx\f[R] و
\f[CR]\-Xms\f[R]) و پرچم‌های مربوط به بازیافت حافظه (garbage collection)
مانند قبل به عملکرد خود ادامه می‌دهند.
.RE
.TP
\f[CR]\-XX:\-CompactStrings\f[R]
ویژگی Compact Strings را غیرفعال می‌کند.
به‌طور پیش‌فرض، این گزینه فعال است.
هنگامی که این گزینه فعال باشد، رشته‌های جاوا که فقط حاوی نویسه‌های
تک‌بایتی هستند، در داخل به‌صورت رشته‌های تک‌بایت به ازای هر نویسه با
استفاده از کدگذاری ISO\-8859\-1 / Latin\-1 ذخیره و بازنمایی می‌شوند.
این امر مقدار فضای مورد نیاز برای رشته‌هایی را که صرفاً حاوی نویسه‌های
تک‌بایتی هستند، تا ۵۰٪ کاهش می‌دهد.
برای رشته‌های جاوایی که حداقل حاوی یک نویسه چندبایتی هستند: این رشته‌ها
با استفاده از کدگذاری UTF\-16 به‌صورت ۲ بایت به ازای هر نویسه ذخیره و
بازنمایی می‌شوند.
غیرفعال کردن ویژگی Compact Strings، استفاده از کدگذاری UTF\-16 را
به‌عنوان بازنمایی داخلی برای تمام رشته‌های جاوا اجباری می‌کند.
.RS
مواردی که غیرفعال کردن Compact Strings در آن‌ها می‌تواند سودمند باشد
شامل موارد زیر است:
.IP \(bu 2
زمانی که مشخص باشد برنامه به شکلی غالب اقدام به تخصیص رشته‌های حاوی
نویسه‌های چندبایتی خواهد کرد
.IP \(bu 2
در رویداد غیرمنتظره‌ای که افتی در کارایی هنگام مهاجرت از Java SE 8 به
Java SE 9 مشاهده شود و تحلیل‌ها نشان دهند که Compact Strings مسبب این
افت کارایی است
در هر دوی این سناریوها، غیرفعال کردن Compact Strings منطقی است.
.RE
.TP
\f[CR]\-XX:ErrorFile=\f[R]\f[I]filename\f[R]
مسیر و نام فایلی را مشخص می‌کند که در صورت وقوع یک خطای غیرقابل بازیابی،
داده‌های خطا در آن نوشته می‌شوند.
به‌طور پیش‌فرض، این فایل در دایرکتوری کاری جاری ایجاد شده و
\f[CR]hs_err_pid\f[R]\f[I]pid\f[R]\f[CR].log\f[R] نامیده می‌شود که در
آن \f[I]pid\f[R] شناسه فرایندی است که با خطا مواجه شده است.
.RS
مثال زیر نحوه تنظیم فایل لاگ پیش‌فرض را نشان می‌دهد (توجه داشته باشید که
شناسه فرایند به‌صورت \f[CR]%p\f[R] مشخص می‌شود):
.RS
.PP
\f[CR]\-XX:ErrorFile=./hs_err_pid%p.log\f[R]
.RE
.IP \(bu 2
\f[B]غیر ویندوز (Non\-Windows):\f[R] مثال زیر نحوه تنظیم گزارش خطا به
\f[CR]/var/log/java/java_error.log\f[R] را نشان می‌دهد:
.RS 2
.RS
.PP
\f[CR]\-XX:ErrorFile=/var/log/java/java_error.log\f[R]
.RE
.RE
.IP \(bu 2
\f[B]ویندوز (Windows):\f[R] مثال زیر نحوه تنظیم فایل گزارش خطا به
\f[CR]C:/log/java/java_error.log\f[R] را نشان می‌دهد:
.RS 2
.RS
.PP
\f[CR]\-XX:ErrorFile=C:/log/java/java_error.log\f[R]
.RE
.RE
اگر فایل از قبل موجود بوده و قابل نوشتن باشد، بازنویسی خواهد شد.
در غیر این صورت، چنانچه فایل نتواند در دایرکتوری مشخص‌شده ایجاد شود
(به دلیل کمبود فضا، مشکل دسترسی یا هر مسئله دیگری)، فایل در دایرکتوری
موقت سیستم‌عامل ایجاد می‌شود:
.IP \(bu 2
\f[B]غیر ویندوز (Non\-Windows):\f[R] دایرکتوری موقت \f[CR]/tmp\f[R] است.
.IP \(bu 2
\f[B]ویندوز (Windows):\f[R] دایرکتوری موقت با مقدار متغیر محیطی
\f[CR]TMP\f[R] مشخص می‌شود؛ اگر آن متغیر محیطی تعریف نشده باشد، از مقدار
متغیر محیطی \f[CR]TEMP\f[R] استفاده خواهد شد.
.RE
.TP
\f[CR]\-XX:+ExtensiveErrorReports\f[R]
گزارش‌دهی اطلاعات جامع‌تر و گسترده‌تر خطا را در \f[CR]ErrorFile\f[R] فعال
می‌کند.
این گزینه می‌تواند در محیط‌هایی که حداکثر اطلاعات مورد نیاز است روشن شود \-
حتی اگر لاگ‌های حاصل بسیار حجیم باشند و/یا حاوی اطلاعاتی باشند که حساس تلقی
شوند.
این اطلاعات می‌تواند از نگارشی به نگارش دیگر و در بسترهای مختلف تفاوت داشته
باشد.
به‌طور پیش‌فرض این گزینه غیرفعال است.
.TP
\f[CR]\-XX:FlightRecorderOptions=\f[R]\f[I]parameter\f[R]\f[CR]=\f[R]\f[I]value\f[R] (یا) \f[CR]\-XX:FlightRecorderOptions:\f[R]\f[I]parameter\f[R]\f[CR]=\f[R]\f[I]value\f[R]
پارامترهایی را که رفتار JFR را کنترل می‌کنند تنظیم می‌کند.
می‌توان چندین پارامتر را با جدا کردن آن‌ها به‌وسیله ویرگول مشخص کرد.
.RS
فهرست زیر شامل ورودی‌های دردسترس \f[I]parameter\f[R]\f[CR]=\f[R]\f[I]value\f[R]
برای JFR است:
.TP
\f[CR]globalbuffersize=\f[R]\f[I]size\f[R]
میزان کل حافظه اصلی مورد استفاده برای نگهداری داده‌ها را مشخص می‌کند.
مقدار پیش‌فرض بر اساس مقدار مشخص‌شده برای \f[CR]memorysize\f[R] تعیین
می‌شود.
برای تغییر دادن اندازه بافرهای سراسری، پارامتر \f[CR]memorysize\f[R] را
تغییر دهید.
.TP
\f[CR]maxchunksize=\f[R]\f[I]size\f[R]
حداکثر اندازه (به بایت) تکه‌های داده در یک ضبط (recording) را مشخص می‌کند.
برای تعیین اندازه بر حسب مگابایت (MB)، حرف \f[CR]m\f[R] یا \f[CR]M\f[R]،
و برای تعیین اندازه بر حسب گیگابایت (GB)، حرف \f[CR]g\f[R] یا \f[CR]G\f[R]
را به انتها بیفزایید.
به‌طور پیش‌فرض، حداکثر اندازه تکه‌های داده روی 12 MB تنظیم شده است.
حداقل مقدار مجاز 1 MB است.
.TP
\f[CR]memorysize=\f[R]\f[I]size\f[R]
تعیین می‌کند چه مقدار حافظه بافر باید استفاده شود، و پارامترهای
\f[CR]globalbuffersize\f[R] و \f[CR]numglobalbuffers\f[R] را بر اساس
اندازه مشخص‌شده تنظیم می‌کند.
برای تعیین اندازه بر حسب مگابایت (MB)، حرف \f[CR]m\f[R] یا \f[CR]M\f[R]،
و برای تعیین اندازه بر حسب گیگابایت (GB)، حرف \f[CR]g\f[R] یا \f[CR]G\f[R]
را به انتها بیفزایید.
به‌طور پیش‌فرض، اندازه حافظه روی 10 MB تنظیم شده است.
.TP
\f[CR]numglobalbuffers\f[R]
تعداد بافرهای سراسری مورد استفاده را مشخص می‌کند.
مقدار پیش‌فرض بر اساس اندازه حافظه مشخص‌شده تعیین می‌شود.
برای تغییر تعداد بافرهای سراسری، پارامتر \f[CR]memorysize\f[R] را تغییر
دهید..TP
\f[CR]old\-object\-queue\-size=number\-of\-objects\f[R]
حداکثر تعداد اشیاء قدیمی برای ردیابی.
به‌طور پیش‌فرض، تعداد اشیاء روی 256 تنظیم شده است.
.TP
\f[CR]preserve\-repository=\f[R]{\f[CR]true\f[R]|\f[CR]false\f[R]}
مشخص می‌کند که آیا فایل‌های ذخیره‌شده در مخزن دیسک باید پس از خروج JVM نگهداری شوند یا خیر.
اگر false باشد، فایل‌ها حذف می‌شوند.
به‌طور پیش‌فرض، این پارامتر غیرفعال است.
.TP
\f[CR]repository=\f[R]\f[I]path\f[R]
مخزن (یک دایرکتوری) را برای ذخیره‌سازی موقت روی دیسک مشخص می‌کند.
به‌طور پیش‌فرض، از دایرکتوری موقت سیستم استفاده می‌شود.
.TP
\f[CR]retransform=\f[R]{\f[CR]true\f[R]|\f[CR]false\f[R]}
مشخص می‌کند که آیا کلاس‌های رویداد باید با استفاده از JVMTI بازدگرگون (retransform) شوند یا خیر.
اگر false باشد، تجهیز (instrumentation) هنگام بارگذاری کلاس‌های رویداد اضافه می‌شود.
به‌طور پیش‌فرض، این پارامتر فعال است.
.TP
\f[CR]stackdepth=\f[R]\f[I]depth\f[R]
عمق پشته برای ردگیری‌های پشته (stack traces).
به‌طور پیش‌فرض، عمق روی ۶۴ فراخوانی متد تنظیم شده است.
حداکثر مقدار ۲۰۴۸ است.
مقادیر بزرگ‌تر از ۶۴ می‌توانند سربار قابل‌توجهی ایجاد کرده و کارایی را کاهش دهند.
.TP
\f[CR]threadbuffersize=\f[R]\f[I]size\f[R]
اندازه بافر محلی به‌ازای هر نخ (به بایت) را مشخص می‌کند.
به‌طور پیش‌فرض، اندازه بافر محلی روی ۸ کیلوبایت تنظیم شده و حداقل مقدار آن ۴ کیلوبایت است.
بازنویسی این پارامتر می‌تواند کارایی را کاهش دهد و توصیه نمی‌شود.
.RE
.TP
\f[CR]\-XX:LargePageSizeInBytes=\f[R]\f[I]size\f[R]
حداکثر اندازه صفحه بزرگ (به بایت) مورد استفاده توسط JVM را تنظیم می‌کند.
آرگومان \f[I]size\f[R] باید یک اندازه صفحه معتبر و پشتیبانی‌شده توسط محیط باشد تا تأثیر بگذارد.
برای مشخص کردن کیلوبایت، حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت، \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت، \f[CR]g\f[R] یا \f[CR]G\f[R] را ضمیمه کنید.
به‌طور پیش‌فرض، اندازه روی 0 تنظیم شده است؛ بدین معنی که JVM از اندازه پیش‌فرض صفحه بزرگِ محیط به عنوان حداکثر اندازه برای صفحات بزرگ استفاده خواهد کرد.
بخش \f[B]Large Pages\f[R] را ببینید.
.RS
مثال زیر نحوه تنظیم اندازه صفحه بزرگ روی ۱ گیگابایت (GB) را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:LargePageSizeInBytes=1g\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxDirectMemorySize=\f[R]\f[I]size\f[R]
حداکثر اندازه کل (به بایت) تخصیص‌های بافر مستقیم (direct-buffer) در بسته \f[CR]java.nio\f[R] را تنظیم می‌کند.
برای مشخص کردن کیلوبایت، حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت، \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت، \f[CR]g\f[R] یا \f[CR]G\f[R] را ضمیمه کنید.
اگر تنظیم نشود، این پرچم نادیده گرفته شده و JVM اندازه تخصیص‌های بافر مستقیم NIO را به‌طور خودکار انتخاب می‌کند.
.RS
مثال‌های زیر نحوه تنظیم اندازه NIO به ۱۰۲۴ کیلوبایت در واحدهای مختلف را نشان می‌دهند:
.IP
.EX
\-XX:MaxDirectMemorySize=1m
\-XX:MaxDirectMemorySize=1024k
\-XX:MaxDirectMemorySize=1048576
.EE
.RE
.TP
\f[CR]\-XX:\-MaxFDLimit\f[R]
تلاش برای تنظیم حد نرم (soft limit) تعداد توصیف‌کننده‌های فایل باز روی حد سخت (hard limit) را غیرفعال می‌کند.
به‌طور پیش‌فرض، این گزینه در تمام پلتفرم‌ها فعال است، اما در Windows نادیده گرفته می‌شود.
تنها زمانی که ممکن است نیاز به غیرفعال کردن آن داشته باشید در macOS است، جایی که استفاده از آن حداکثر مقدار ۱۰۲۴۰ را تحمیل می‌کند که کمتر از حداکثر واقعی سیستم است.
.TP
\f[CR]\-XX:NativeMemoryTracking=\f[R]\f[I]mode\f[R]
حالت ردیابی مصرف حافظه بومی (native memory) ماشین مجازی جاوا (JVM) را مشخص می‌کند.
آرگومان‌های ممکنِ \f[I]mode\f[R] برای این گزینه شامل موارد زیر است:
.RS
.TP
\f[CR]off\f[R]
دستور می‌دهد که مصرف حافظه بومی JVM ردیابی نشود.
اگر گزینه \f[CR]\-XX:NativeMemoryTracking\f[R] را مشخص نکنید، این رفتار پیش‌فرض است.
.TP
\f[CR]summary\f[R]
مصرف حافظه را فقط بر اساس زیرسیستم‌های JVM نظیر Java heap، کلاس، کد و نخ (thread) ردیابی می‌کند.
.TP
\f[CR]detail\f[R]
علاوه بر ردیابی مصرف حافظه توسط زیرسیستم‌های JVM، مصرف حافظه را بر اساس هر \f[CR]CallSite\f[R] مجزا، ناحیه حافظه مجازی مجزا و نواحی تخصیص‌یافته (committed) آن ردیابی می‌کند.
.RE
.TP
\f[CR]\-XX:TrimNativeHeapInterval=\f[R]\f[I]millis\f[R]
بازه زمانی، به میلی‌ثانیه، که در آن JVM هیپ بومی (native heap) را هرس (trim) می‌کند.
مقادیر کمتر، حافظه را مشتاقانه‌تر بازپس‌گیری می‌کنند اما هزینه آن سربار بالاتر است.
مقدار 0 (پیش‌فرض) هرس هیپ بومی را غیرفعال می‌کند.
هرس هیپ بومی در یک نخ اختصاصی انجام می‌شود.
.RS
این گزینه فقط روی Linux با کتابخانه سی گنو (glibc) پشتیبانی می‌شود.
.RE
.TP
\f[CR]\-XX:ObjectAlignmentInBytes=\f[R]\f[I]alignment\f[R]
هم‌ترازی حافظه اشیاء جاوا را (به بایت) تنظیم می‌کند.
به‌طور پیش‌فرض، این مقدار روی ۸ بایت تنظیم شده است.
مقدار مشخص‌شده باید توانی از ۲ باشد و حتماً در بازه ۸ تا ۲۵۶ (شامل هر دو) قرار گیرد.
این گزینه استفاده از اشاره‌گرهای فشرده (compressed pointers) را با اندازه‌های بزرگ Java heap امکان‌پذیر می‌سازد.
.RS
محدودیت اندازه heap به بایت به صورت زیر محاسبه می‌شود:
.RS
.PP
\f[CR]4GB * ObjectAlignmentInBytes\f[R]
.RE
.RS
.PP
\f[B]نکته:\f[R] با افزایش مقدار هم‌ترازی، فضای استفاده‌نشده میان اشیاء نیز افزایش می‌یابد.
در نتیجه، ممکن است هیچ مزیتی از به‌کارگیری اشاره‌گرهای فشرده با اندازه‌های بزرگ Java heap به دست نیاورید.
.RE
.RE
.TP
\f[CR]\-XX:OnError=\f[R]\f[I]string\f[R]
یک دستور سفارشی یا مجموعه‌ای از دستورهای جداشده با نقطه‌ویرگول را برای اجرا هنگام وقوع خطای غیرقابل جبران تنظیم می‌کند.
اگر رشته شامل فاصله باشد، باید درون علامت نقل‌قول قرار گیرد.
.RS
.IP \(bu 2
\f[B]سیستم‌های غیر Windows:\f[R] مثال زیر نشان می‌دهد که چگونه می‌توان از گزینه \f[CR]\-XX:OnError\f[R] برای اجرای دستور \f[CR]gcore\f[R] جهت ایجاد تصویر هسته (core image) و راه‌اندازی اشکال‌زدای \f[CR]gdb\f[R] برای اتصال به فرایند در صورت وقوع خطای غیرقابل جبران استفاده کرد (\f[CR]%p\f[R] نشان‌دهنده شناسه فرایند فعلی است):
.RS 2
.RS
.PP
\f[CR]\-XX:OnError=\(dqgcore %p;gdb \-p %p\(dq\f[R]
.RE
.RE
.IP \(bu 2
\f[B]Windows:\f[R] مثال زیر نشان می‌دهد که چگونه می‌توان از گزینه \f[CR]\-XX:OnError\f[R] برای اجرای ابزار \f[CR]userdump.exe\f[R] جهت دریافت رونوشت خرابی (crash dump) در صورت بروز خطای غیرقابل جبران استفاده کرد (\f[CR]%p\f[R] شناسه فرایند فعلی را مشخص می‌کند).
این مثال فرض می‌کند که مسیر ابزار \f[CR]userdump.exe\f[R] در متغیر محیطی \f[CR]PATH\f[R] مشخص شده است:
.RS 2
.RS
.PP
\f[CR]\-XX:OnError=\(dquserdump.exe %p\(dq\f[R]
.RE
.RE
.RE
.TP
\f[CR]\-XX:OnOutOfMemoryError=\f[R]\f[I]string\f[R]
یک دستور سفارشی یا مجموعه‌ای از دستورهای جداشده با نقطه‌ویرگول را برای اجرا در زمانی که استثنای \f[CR]OutOfMemoryError\f[R] برای نخستین بار توسط JVM پرتاب می‌شود، تنظیم می‌کند.
اگر رشته شامل فاصله باشد، باید درون علامت نقل‌قول قرار گیرد.
برای نمونه‌ای از رشته دستور، به توضیحات گزینه \f[CR]\-XX:OnError\f[R] مراجعه کنید.
این گزینه فقط برای استثناهای \f[CR]OutOfMemoryError\f[R] ناشی از اتمام Java Heap اعمال می‌شود؛ این مورد برای استثناهای \f[CR]OutOfMemoryError\f[R] که مستقیماً از کد جاوا پرتاب می‌شوند و همچنین مواردی که توسط JVM به دلیل اتمام سایر منابع (مانند خطاهای ایجاد نخ بومی) رخ می‌دهند اعمال نخواهد شد..TP
\f[CR]\-XX:+PrintCommandLineFlags\f[R]
چاپ فلگ‌های انتخاب‌شده به‌صورت ارگونومیک توسط JVM را که در خط فرمان ظاهر شده‌اند، فعال می‌کند.
دانستن مقادیر ارگونومیک تنظیم‌شده توسط JVM، مانند اندازه فضای heap و جمع‌آورنده زباله (garbage collector) انتخاب‌شده، می‌تواند مفید باشد.
به‌طور پیش‌فرض، این گزینه غیرفعال است و فلگ‌ها چاپ نمی‌شوند.
.TP
\f[CR]\-XX:+PreserveFramePointer\f[R]
بین استفاده از ثبات RBP به عنوان یک ثبات همه‌منظوره (\f[CR]\-XX:\-PreserveFramePointer\f[R]) و استفاده از ثبات RBP برای نگه‌داری اشاره‌گر فریم (frame pointer) متد در حال اجرای فعلی (\f[CR]\-XX:+PreserveFramePointer\f[R]) انتخاب می‌کند.
اگر اشاره‌گر فریم در دسترس باشد، ابزارهای خارجی ارزیابی کارایی (مانند Linux perf) می‌توانند ردپای پشته (stack trace) دقیق‌تری بسازند.
.TP
\f[CR]\-XX:+PrintNMTStatistics\f[R]
چاپ داده‌های جمع‌آوری‌شده ردیابی حافظه بومی (native memory tracking) را هنگام خروج JVM، در صورتی که ردیابی حافظه بومی فعال باشد (به \f[CR]\-XX:NativeMemoryTracking\f[R] مراجعه کنید)، فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و داده‌های ردیابی حافظه بومی چاپ نمی‌شوند.
.TP
\f[CR]\-XX:SharedArchiveFile=\f[R]\f[I]path\f[R]
مسیر و نام فایل آرشیو اشتراک‌گذاری داده‌های کلاس (CDS) را مشخص می‌کند.
.RS
به \f[B]Application Class Data Sharing\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-XX:+VerifySharedSpaces\f[R]
اگر این گزینه مشخص شود، JVM فایل آرشیو CDS را تنها در صورتی بارگذاری می‌کند که از بررسی یکپارچگی مبتنی بر چکسام‌های CRC32 با موفقیت عبور کند.
هدف از این فلگ، بررسی آسیب‌های غیرعمدی واردشده به فایل‌های آرشیو CDS در حین انتقال یا ذخیره‌سازی است.
برای تضمین امنیت و عملکرد صحیح CDS، کاربر باید اطمینان حاصل کند که فایل‌های آرشیو CDS مورد استفاده برنامه‌های جاوا نمی‌توانند بدون مجوز لازم تغییر یابند.
.TP
\f[CR]\-XX:SharedArchiveConfigFile=\f[R]\f[I]shared_config_file\f[R]
داده‌های اشتراکی اضافی افزوده‌شده به فایل آرشیو را مشخص می‌کند.
.TP
\f[CR]\-XX:SharedClassListFile=\f[R]\f[I]file_name\f[R]
فایل متنی حاوی نام کلاس‌هایی را که باید در آرشیو اشتراک‌گذاری داده‌های کلاس (CDS) ذخیره شوند، مشخص می‌کند.
این فایل شامل نام کامل یک کلاس در هر خط است، با این تفاوت که اسلش‌ها (\f[CR]/\f[R]) جایگزین نقطه‌ها (\f[CR].\f[R]) می‌شوند.
برای نمونه، جهت مشخص کردن کلاس‌های \f[CR]java.lang.Object\f[R] و \f[CR]hello.Main\f[R]، یک فایل متنی حاوی دو خط زیر ایجاد کنید:
.RS
.IP
.EX
java/lang/Object
hello/Main
.EE
کلاس‌هایی که در این فایل متنی مشخص می‌کنید باید شامل کلاس‌هایی باشند که به‌طور معمول توسط برنامه استفاده می‌شوند.
آن‌ها می‌توانند شامل هر کلاسی از مسیرهای کلاس (class paths) برنامه، افزونه یا bootstrap باشند.
به \f[B]Application Class Data Sharing\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-XX:+ShowCodeDetailsInExceptionMessages\f[R]
چاپ پیام‌های بهبودیافته \f[CR]NullPointerException\f[R] را فعال می‌کند.
هنگامی که یک برنامه خطای \f[CR]NullPointerException\f[R] صادر می‌کند، این گزینه به JVM امکان می‌دهد دستورالعمل‌های بایت‌کد برنامه را تحلیل کند تا دقیقاً مشخص شود کدام ارجاع \f[CR]null\f[R] است، و منبع را با یک پیام جزئیات مقدار تهی (null\-detail) شرح دهد.
پیام جزئیات مقدار تهی توسط \f[CR]NullPointerException.getMessage()\f[R] محاسبه و بازگردانده می‌شود، و به عنوان پیام استثنا همراه با متد، نام فایل و شماره خط چاپ خواهد شد.
به‌طور پیش‌فرض، این گزینه فعال است.
.TP
\f[CR]\-XX:+ShowMessageBoxOnError\f[R]
نمایش یک کادر محاوره‌ای را هنگام مواجهه JVM با یک خطای غیرقابل جبران فعال می‌کند.
این امر مانع از خروج JVM می‌شود و فرایند را فعال نگه می‌دارد تا بتوانید یک اشکال‌زدا (debugger) به آن متصل کرده و علت خطا را بررسی کنید.
به‌طور پیش‌فرض، این گزینه غیرفعال است.
.TP
\f[CR]\-XX:StartFlightRecording:\f[R]\f[I]parameter\f[R]\f[CR]=\f[R]\f[I]value\f[R]
یک ضبط JFR را برای برنامه جاوا آغاز می‌کند.
این گزینه معادل دستور عیب‌یابی \f[CR]JFR.start\f[R] است که ضبط را در زمان اجرا آغاز می‌کند.
دستور \f[CR]\-XX:StartFlightRecording:help\f[R] گزینه‌های موجود و نمونه خطوط فرمان را چاپ می‌کند.
هنگام آغاز ضبط JFR می‌توانید مقادیر \f[I]parameter\f[R]\f[CR]=\f[R]\f[I]value\f[R] زیر را تنظیم کنید:
.RS
.TP
\f[CR]delay=\f[R]\f[I]time\f[R]
تأخیر بین زمان راه‌اندازی برنامه جاوا و شروع ضبط را مشخص می‌کند.
پسوند \f[CR]s\f[R] را برای تعیین زمان بر حسب ثانیه، \f[CR]m\f[R] برای دقیقه، \f[CR]h\f[R] برای ساعت، یا \f[CR]d\f[R] برای روز اضافه کنید (برای نمونه، تعیین \f[CR]10m\f[R] به معنی ۱۰ دقیقه است).
به‌طور پیش‌فرض، هیچ تأخیری وجود ندارد و این پارامتر روی 0 تنظیم شده است.
.TP
\f[CR]disk=\f[R]{\f[CR]true\f[R]|\f[CR]false\f[R]}
مشخص می‌کند که آیا داده‌ها حین ضبط روی دیسک نوشته شوند یا خیر.
به‌طور پیش‌فرض، این پارامتر فعال است.
.TP
\f[CR]dumponexit=\f[R]{\f[CR]true\f[R]|\f[CR]false\f[R]}
مشخص می‌کند که آیا ضبط در حال اجرا هنگام خاموش شدن JVM تخلیه (dump) شود یا خیر.
در صورت فعال بودن و وارد نشدن \f[CR]filename\f[R]، ضبط در فایلی در دایرکتوری محل آغاز فرایند نوشته می‌شود.
نام فایل به‌صورت خودکار توسط سیستم تولید می‌شود و شامل شناسه فرایند (PID)، شناسه ضبط و برچسب زمانی فعلی است، شبیه به
\f[CR]hotspot\-pid\-47496\-id\-1\-2018_01_25_19_10_41.jfr\f[R].
به‌طور پیش‌فرض، این پارامتر غیرفعال است.
.TP
\f[CR]duration=\f[R]\f[I]time\f[R]
مدت‌زمان ضبط را مشخص می‌کند.
پسوند \f[CR]s\f[R] را برای تعیین زمان بر حسب ثانیه، \f[CR]m\f[R] برای دقیقه، \f[CR]h\f[R] برای ساعت، یا \f[CR]d\f[R] برای روز اضافه کنید (برای نمونه، تعیین \f[CR]5h\f[R] به معنی ۵ ساعت است).
به‌طور پیش‌فرض، مدت‌زمان نامحدود است و این پارامتر روی 0 تنظیم شده است.
.TP
\f[CR]filename=\f[R]\f[I]path\f[R]
مسیر و نام فایلی را که هنگام توقف ضبط، داده‌ها در آن نوشته می‌شوند مشخص می‌کند؛ برای نمونه:
.RS
.IP \(bu 2
\f[CR]recording.jfr\f[R]
.IP \(bu 2
\f[CR]/home/user/recordings/recording.jfr\f[R]
.IP \(bu 2
\f[CR]c:\(rsrecordings\(rsrecording.jfr\f[R]
اگر %p و/یا %t در نام فایل مشخص شده باشد، به ترتیب به PID مربوط به JVM و برچسب زمانی فعلی بسط می‌یابد.
نام فایل همچنین می‌تواند یک دایرکتوری باشد؛ در این حالت نام فایل بر اساس PID و تاریخ فعلی در دایرکتوری مشخص‌شده تولید می‌شود.
.RE
.TP
\f[CR]name=\f[R]\f[I]identifier\f[R]
هم نام و هم شناسه یک ضبط را دریافت می‌کند.
.TP
\f[CR]maxage=\f[R]\f[I]time\f[R]
حداکثر عمر داده‌های دیسک برای نگه‌داری در ضبط را مشخص می‌کند.
این پارامتر تنها زمانی معتبر است که پارامتر \f[CR]disk\f[R] روی \f[CR]true\f[R] تنظیم شده باشد.
پسوند \f[CR]s\f[R] را برای تعیین زمان بر حسب ثانیه، \f[CR]m\f[R] برای دقیقه، \f[CR]h\f[R] برای ساعت، یا \f[CR]d\f[R] را برای روز اضافه کنید (برای نمونه، تعیین \f[CR]30s\f[R] به معنی ۳۰ ثانیه است).
به‌طور پیش‌فرض، حداکثر عمر نامحدود است و این پارامتر روی \f[CR]0s\f[R] تنظیم شده است.
.TP
\f[CR]maxsize=\f[R]\f[I]size\f[R]
حداکثر اندازه (بر حسب بایت) داده‌های دیسک برای نگه‌داری در ضبط را مشخص می‌کند.
این پارامتر تنها زمانی معتبر است که پارامتر \f[CR]disk\f[R] روی \f[CR]true\f[R] تنظیم شده باشد.
مقدار نباید کمتر از مقدار پارامتر \f[CR]maxchunksize\f[R] باشد که با \f[CR]\-XX:FlightRecorderOptions\f[R] تنظیم شده است.
پسوند \f[CR]m\f[R] یا \f[CR]M\f[R] را برای تعیین اندازه بر حسب مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] را برای گیگابایت اضافه کنید.
به‌طور پیش‌فرض، حداکثر اندازه داده‌های دیسک نامحدود است و این پارامتر روی \f[CR]0\f[R] تنظیم شده است.
.TP
\f[CR]path\-to\-gc\-roots=\f[R]{\f[CR]true\f[R]|\f[CR]false\f[R]}
مشخص می‌کند که آیا مسیر به ریشه‌های جمع‌آوری زباله (GC roots) در پایان ضبط جمع‌آوری شود یا خیر.
به‌طور پیش‌فرض، این پارامتر غیرفعال است.
.RS
مسیر به ریشه‌های GC برای یافتن نشت‌های حافظه (memory leaks) مفید است، اما جمع‌آوری آن زمان‌بر است.
این گزینه را تنها زمانی فعال کنید که ضبط را برای برنامه‌ای آغاز می‌کنید که مشکوک به نشت حافظه است.
اگر پارامتر \f[CR]settings\f[R] روی \f[CR]profile\f[R] تنظیم شده باشد، ردپای پشته (stack trace) مکانی که شیء بالقوه دارای نشت در آن تخصیص یافته بود، در اطلاعات جمع‌آوری‌شده گنجانده می‌شود.
.RE
.TP
\f[CR]report\-on\-exit=\f[R]\f[I]identifier\f[R]
نام نمایی (view) را که باید هنگام خاموش شدن ماشین مجازی جاوا (JVM) نمایش داده شود، مشخص می‌کند.
برای مشخص کردن بیش از یک نما، از پارامتر report\-on\-exit به‌طور مکرر استفاده کنید.
اگر گزینه disk روی false تنظیم شده باشد، این گزینه در دسترس نیست.
برای مشاهده فهرست نماهای موجود، به \f[CR]jfr help view\f[R] مراجعه کنید.
به‌طور پیش‌فرض، هیچ گزارشی تولید نمی‌شود..TP
\f[CR]settings=\f[R]\f[I]path\f[R]
مسیر و نام فایل تنظیمات رویداد (از نوع JFC) را مشخص می‌کند.
به‌طور پیش‌فرض، فایل \f[CR]default.jfc\f[R] که در
\f[CR]JAVA_HOME/lib/jfr\f[R] قرار دارد استفاده می‌شود.
این فایل تنظیمات پیش‌فرض، مجموعه‌ای از پیش‌تعریف‌شده از اطلاعات را با
سربار اندک جمع‌آوری می‌کند، بنابراین حداقل تأثیر را بر کارایی دارد و می‌توان
از آن برای ضبط‌هایی که به‌طور پیوسته اجرا می‌شوند استفاده کرد.
.RS
فایل تنظیمات دومی نیز ارائه شده است، یعنی profile.jfc، که داده‌های
بیشتری را نسبت به پیکربندی پیش‌فرض فراهم می‌کند، اما ممکن است سربار بیشتری
داشته باشد و بر کارایی تأثیر بگذارد.
زمانی که به اطلاعات بیشتری نیاز است، از این پیکربندی برای دوره‌های زمانی
کوتاه استفاده کنید.
.RE
می‌توانید مقادیر چندین پارامتر را با جدا کردن آن‌ها با ویرگول مشخص کنید.
تنظیمات رویداد و گزینه‌های .jfc را می‌توان با استفاده از نحو زیر
مشخص کرد:
.TP
\f[CR]option=\f[R]\f[I]value\f[R]
مقدار گزینه‌ای که باید تغییر کند را مشخص می‌کند.
برای فهرست کردن گزینه‌های موجود، از ابزار \f[CR]JAVA_HOME\f[R]/bin/jfr استفاده کنید.
.TP
\f[CR]event\-setting=\f[R]\f[I]value\f[R]
مقدار تنظیم رویداد را برای تغییر مشخص می‌کند.
از این قالب استفاده کنید: \f[CR]<event\-name>#<setting\-name>=<value>\f[R].
برای افزودن یک تنظیم رویداد جدید، یک \(aq+\(aq به ابتدای نام رویداد اضافه کنید.
می‌توانید با جدا کردن با ویرگول، مقادیر چندین تنظیم رویداد و گزینه .jfc را
مشخص کنید.
در صورت بروز تداخل بین یک پارامتر و یک گزینه .jfc، پارامتر
اولویت خواهد داشت.
جداکننده فاصله خالی را می‌توان برای مقادیر بازه زمانی حذف کرد، مانند
20ms.
برای اطلاعات بیشتر درباره نحو تنظیمات، به Javadoc بسته
jdk.jfr مراجعه کنید.
برای اینکه در حین راه‌اندازی فقط هشدارها و خطاهای JFR را مشاهده کنید،
\-Xlog:jfr+startup=warning را تنظیم نمایید.
.RE
.TP
\f[CR]\-XX:ThreadStackSize=\f[R]\f[I]size\f[R]
اندازه پشته ریسه (thread stack) جاوا را (به کیلوبایت) تنظیم می‌کند.
استفاده از یک پسوند مقیاس، مانند \f[CR]k\f[R]، منجر به مقیاس‌بندی مقدار
کیلوبایت می‌شود، به‌طوری که \f[CR]\-XX:ThreadStackSize=1k\f[R] اندازه
پشته ریسه جاوا را روی 1024*1024 بایت یا ۱ مگابایت تنظیم می‌کند.
مقدار پیش‌فرض به بستر بستگی دارد.
به عنوان مثال:
.RS
.IP \(bu 2
Linux/x64: 1024 KB
.IP \(bu 2
Linux/Aarch64: 2048 KB
.IP \(bu 2
macOS/x64: 1024 KB
.IP \(bu 2
macOS/Aarch64: 2048 KB
.IP \(bu 2
Windows: مقدار پیش‌فرض به حافظه مجازی بستگی دارد
مثال‌های زیر نحوه تنظیم اندازه پشته ریسه را روی ۱
مگابایت در واحدهای مختلف نشان می‌دهند:
.IP
.EX
\-XX:ThreadStackSize=1k
\-XX:ThreadStackSize=1024
.EE
این گزینه مشابه با \f[CR]\-Xss\f[R] است.
.RE
.TP
\f[CR]\-XX:+UseCompactObjectHeaders\f[R]
هدرهای فشرده اشیاء (compact object headers) را فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است.
فعال‌سازی این گزینه ردپای حافظه در هیپ (heap) جاوا را (به‌طور میانگین) ۴
بایت به ازای هر شیء کاهش داده و اغلب کارایی را بهبود می‌بخشد.
.RS
این ویژگی در حین ادامه ارزیابی‌ها همچنان به‌طور پیش‌فرض غیرفعال خواهد ماند.
انتظار می‌رود در نسخه‌های آتی به‌طور پیش‌فرض فعال شود و در نهایت
تنها حالت عملیاتی خواهد بود.
.RE
.TP
\f[CR]\-XX:\-UseCompressedOops\f[R]
استفاده از اشاره‌گرهای فشرده (compressed pointers) را غیرفعال می‌کند.
به‌طور پیش‌فرض، این گزینه فعال است و از اشاره‌گرهای فشرده استفاده می‌شود.
این کار به‌طور خودکار حداکثر اندازه هیپ ارگونومیک جاوا را به حداکثر مقدار
حافظه‌ای که می‌تواند توسط اشاره‌گرهای فشرده پوشش داده شود محدود می‌کند.
به‌طور پیش‌فرض این محدوده ۳۲ گیگابایت است.
.RS
با فعال بودن compressed oops، ارجاعات اشیاء به‌جای اشاره‌گرهای ۶۴ بیتی به‌صورت
آفست‌های ۳۲ بیتی نمایش داده می‌شوند که معمولاً هنگام اجرای برنامه با اندازه‌های
هیپ جاوا کوچکتر از محدوده اشاره‌گر compressed oops، کارایی را افزایش می‌دهد.
این گزینه فقط برای JVMهای ۶۴ بیتی کار می‌کند.
امکان استفاده از اشاره‌گرهای فشرده با اندازه‌های هیپ جاوا بزرگتر
از ۳۲ گیگابایت نیز وجود دارد.
گزینه \f[CR]\-XX:ObjectAlignmentInBytes\f[R] را ببینید.
.RE
.TP
\f[CR]\-XX:\-UseContainerSupport\f[R]
\f[B]فقط لینوکس:\f[R] اکنون VM پشتیبانی خودکار از تشخیص کانتینر را فراهم
می‌کند، که به ماشین مجازی اجازه می‌دهد مقدار حافظه و تعداد پردازنده‌های
در دسترس یک فرآیند جاوا که در کانتینرهای docker اجرا می‌شود را تعیین کند.
از این اطلاعات برای تخصیص منابع سیستم استفاده می‌شود.
مقدار پیش‌فرض این پرچم \f[CR]true\f[R] است و پشتیبانی از کانتینر
به‌طور پیش‌فرض فعال است.
می‌توان آن را با \f[CR]\-XX:\-UseContainerSupport\f[R] غیرفعال کرد.
.RS
قابلیت Unified Logging برای کمک به عیب‌یابی مسائل مربوط به این
پشتیبانی در دسترس است.
برای حداکثر ثبت رویدادها از اطلاعات کانتینر، از
\f[CR]\-Xlog:os+container=trace\f[R] استفاده کنید.
برای توضیحات مربوط به استفاده از Unified Logging، بخش
\f[B]Enable Logging with the JVM Unified Logging Framework\f[R] را ببینید.
.RE
.TP
\f[CR]\-XX:+UseLargePages\f[R]
استفاده از حافظه با صفحات بزرگ (large page memory) را فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و از حافظه با صفحات بزرگ استفاده نمی‌شود.
.RS
بخش \f[B]Large Pages\f[R] را ببینید.
.RE
.TP
\f[CR]\-XX:+UseTransparentHugePages\f[R]
\f[B]فقط لینوکس:\f[R] استفاده از صفحات بزرگی را که می‌توانند به‌طور
پویا رشد کنند یا کوچک شوند فعال می‌کند.
این گزینه به‌طور پیش‌فرض غیرفعال است.
ممکن است با transparent huge pages دچار مشکلات کارایی شوید، زیرا
سیستم‌عامل صفحات دیگر را برای ایجاد صفحات بزرگ جابه‌جا می‌کند؛ این گزینه
برای اهداف آزمایشی در دسترس قرار گرفته است.
.TP
\f[CR]\-XX:+AllowUserSignalHandlers\f[R]
\f[B]غیر ویندوز:\f[R] امکان نصب گرداننده‌های سیگنال (signal handlers) را
توسط برنامه فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و برنامه اجازه نصب
گرداننده‌های سیگنال را ندارد.
.TP
\f[CR]\-XX:VMOptionsFile=\f[R]\f[I]filename\f[R]
به کاربر اجازه می‌دهد گزینه‌های VM را در یک فایل مشخص کند، به عنوان مثال:
\f[CR]java \-XX:VMOptionsFile=/var/my_vm_options HelloWorld\f[R].
.TP
\f[CR]\-XX:UseBranchProtection=\f[R]\f[I]mode\f[R]
\f[B]فقط لینوکس AArch64:\f[R] حالت حفاظت از انشعاب (branch protection) را مشخص می‌کند.
همه گزینه‌ها به جز \f[CR]none\f[R] نیازمند این هستند که VM با فعال بودن
حفاظت از انشعاب کامپایل شده باشد.
علاوه بر این، برای حفاظت کامل، هرگونه کتابخانه محلی (native) ارائه‌شده توسط
برنامه‌ها نیز باید با همان سطح از حفاظت کامپایل شده باشد.
.RS
آرگومان‌های \f[I]mode\f[R] ممکن برای این گزینه شامل موارد زیر است:
.TP
\f[CR]none\f[R]
از حفاظت انشعاب استفاده نمی‌شود.
این مقدار پیش‌فرض است.
.TP
\f[CR]standard\f[R]
تمام حالت‌های حفاظت انشعاب موجود در بستر جاری را فعال می‌کند.
.TP
\f[CR]pac\-ret\f[R]
حفاظت در برابر حملات مبتنی بر ROP را فعال می‌کند.
(فقط AArch64 8.3+)
.RE.SH "گزینه‌های پیشرفته کامپایلر JIT برای جاوا (ADVANCED JIT COMPILER OPTIONS FOR JAVA)"
این گزینه‌های \f[CR]java\f[R] کامپایل پویای درجا (JIT) انجام‌شده توسط Java HotSpot VM را کنترل می‌کنند.
.TP
\f[CR]\-XX:AllocateInstancePrefetchLines=\f[R]\f[I]lines\f[R]
تعداد خطوطی که باید جلوتر از اشاره‌گر تخصیص نمونه پیش‌واکشی (prefetch) شوند را تنظیم می‌کند.
به‌طور پیش‌فرض، تعداد خطوط پیش‌واکشی روی 1 تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:AllocateInstancePrefetchLines=1\f[R]
.RE
.RE
.TP
\f[CR]\-XX:AllocatePrefetchDistance=\f[R]\f[I]size\f[R]
اندازه (به بایت) فاصله پیش‌واکشی را برای تخصیص شیء تنظیم می‌کند.
حافظه‌ای که قرار است با مقدار اشیاء جدید نوشته شود، تا این فاصله با شروع از نشانی آخرین شیء تخصیص‌یافته پیش‌واکشی می‌شود.
هر رشته (thread) جاوا نقطه تخصیص اختصاصی خود را دارد.
.RS
مقادیر منفی نشان می‌دهند که فاصله پیش‌واکشی بر اساس بستر (platform) انتخاب می‌شود.
مقادیر مثبت تعداد بایت‌ها برای پیش‌واکشی هستند.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] را برای گیگابایت اضافه کنید.
مقدار پیش‌فرض روی \-1 تنظیم شده است.
مثال زیر نحوه تنظیم فاصله پیش‌واکشی به 1024 بایت را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:AllocatePrefetchDistance=1024\f[R]
.RE
.RE
.TP
\f[CR]\-XX:AllocatePrefetchInstr=\f[R]\f[I]instruction\f[R]
دستورالعمل پیش‌واکشی را برای پیش‌واکشی جلوتر از اشاره‌گر تخصیص تنظیم می‌کند.
مقادیر ممکن از 0 تا 3 هستند.
دستورالعمل‌های واقعی مرتبط با این مقادیر به بستر (platform) بستگی دارد.
به‌طور پیش‌فرض، دستورالعمل پیش‌واکشی روی 0 تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:AllocatePrefetchInstr=0\f[R]
.RE
.RE
.TP
\f[CR]\-XX:AllocatePrefetchLines=\f[R]\f[I]lines\f[R]
تعداد خطوط حافظه موقت (cache lines) را که باید پس از آخرین تخصیص شیء با استفاده از دستورالعمل‌های پیش‌واکشی تولیدشده در کد کامپایل‌شده بارگذاری شوند، تنظیم می‌کند.
اگر آخرین شیء تخصیص‌یافته یک نمونه (instance) باشد، مقدار پیش‌فرض 1 و اگر یک آرایه (array) باشد، 3 است.
.RS
مثال زیر نحوه تنظیم تعداد خطوط حافظه موقتِ بارگذاری‌شده به 5 را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:AllocatePrefetchLines=5\f[R]
.RE
.RE
.TP
\f[CR]\-XX:AllocatePrefetchStepSize=\f[R]\f[I]size\f[R]
اندازه گام (به بایت) را برای دستورالعمل‌های متوالی پیش‌واکشی تنظیم می‌کند.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] را برای گیگابایت اضافه کنید.
به‌طور پیش‌فرض، اندازه گام روی 16 بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:AllocatePrefetchStepSize=16\f[R]
.RE
.RE
.TP
\f[CR]\-XX:AllocatePrefetchStyle=\f[R]\f[I]style\f[R]
سبک کد تولیدشده را برای دستورالعمل‌های پیش‌واکشی تعیین می‌کند.
آرگومان \f[I]style\f[R] یک عدد صحیح از 0 تا 3 است:
.RS
.TP
\f[CR]0\f[R]
دستورالعمل‌های پیش‌واکشی را تولید نکن.
.TP
\f[CR]1\f[R]
دستورالعمل‌های پیش‌واکشی را پس از هر تخصیص اجرا کن.
این تنظیم پیش‌فرض است.
.TP
\f[CR]2\f[R]
برای تعیین زمان اجرای دستورالعمل‌های پیش‌واکشی، از اشاره‌گر واترمارکِ بلوک تخصیص محلی رشته (TLAB) استفاده کن.
.TP
\f[CR]3\f[R]
برای هر خط حافظه موقت (cache line)، یک دستورالعمل پیش‌واکشی تولید کن.
.RE
.TP
\f[CR]\-XX:+BackgroundCompilation\f[R]
کامپایل در پس‌زمینه را فعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
برای غیرفعال کردن کامپایل در پس‌زمینه، \f[CR]\-XX:\-BackgroundCompilation\f[R] را مشخص کنید (این کار معادل تعیین \f[CR]\-Xbatch\f[R] است).
.TP
\f[CR]\-XX:CICompilerCount=\f[R]\f[I]threads\f[R]
تعداد رشته‌های (threads) کامپایلر را برای استفاده در کامپایل تنظیم می‌کند.
به‌طور پیش‌فرض، تعداد رشته‌های کامپایلر بسته به تعداد CPUها و حافظه در دسترس برای کد کامپایل‌شده، به‌صورت خودکار انتخاب می‌شود.
مثال زیر نحوه تنظیم تعداد رشته‌ها به 2 را نشان می‌دهد:
.RS
.RS
.PP
\f[CR]\-XX:CICompilerCount=2\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+UseDynamicNumberOfCompilerThreads\f[R]
ایجاد پویای رشته‌های کامپایلر تا سقف مشخص‌شده توسط \f[CR]\-XX:CICompilerCount\f[R].
این گزینه به‌طور پیش‌فرض فعال است.
.TP
\f[CR]\-XX:CompileCommand=\f[R]\f[I]command\f[R]\f[CR],\f[R]\f[I]method\f[R][\f[CR],\f[R]\f[I]option\f[R]]
یک \f[I]command\f[R] را برای اجرا روی یک \f[I]method\f[R] مشخص می‌کند.
برای نمونه، جهت مستثنی کردن متد \f[CR]indexOf()\f[R] از کلاس \f[CR]String\f[R] از کامپایل شدن، از دستور زیر استفاده کنید:
.RS
.RS
.PP
\f[CR]\-XX:CompileCommand=exclude,java/lang/String.indexOf\f[R]
.RE
توجه داشته باشید که نام کامل کلاس مشخص می‌شود، شامل همه بسته‌ها و زیربسته‌ها که با اسلش (\f[CR]/\f[R]) از هم جدا شده‌اند.
برای سهولت در عملیات برش و چسباندن (cut-and-paste)، همچنین امکان استفاده از قالب نام متد تولیدشده توسط گزینه‌های \f[CR]\-XX:+PrintCompilation\f[R] و \f[CR]\-XX:+LogCompilation\f[R] وجود دارد:
.RS
.PP
\f[CR]\-XX:CompileCommand=exclude,java.lang.String::indexOf\f[R]
.RE
اگر متد بدون امضا (signature) مشخص شود، دستور روی همه متدهای دارای نام مشخص‌شده اعمال می‌شود.
با این حال، می‌توانید امضای متد را نیز در قالب فایل کلاس مشخص کنید.
در این حالت، باید آرگومان‌ها را درون علامت نقل‌قول قرار دهید؛ زیرا در غیر این صورت، پوسته (shell) با نقطه ویرگول به‌عنوان پایان دستور رفتار خواهد کرد.
برای نمونه، اگر می‌خواهید فقط متد \f[CR]indexOf(String)\f[R] از کلاس \f[CR]String\f[R] از کامپایل شدن مستثنی شود، از عبارت زیر استفاده کنید:
.RS
.PP
\f[CR]\-XX:CompileCommand=\(dqexclude,java/lang/String.indexOf,(Ljava/lang/String;)I\(dq\f[R]
.RE
همچنین می‌توانید از علامت ستاره (*) به عنوان نویسه عام (wildcard) برای نام‌های کلاس و متد استفاده کنید.
برای نمونه، برای مستثنی کردن تمام متدهای \f[CR]indexOf()\f[R] در همه کلاس‌ها از کامپایل شدن، از عبارت زیر استفاده کنید:
.RS
.PP
\f[CR]\-XX:CompileCommand=exclude,*.indexOf\f[R]
.RE
ویرگول‌ها و نقطه‌ها نام‌های مستعاری برای فاصله‌ها هستند که ارسال دستورات کامپایلر را از طریق پوسته آسان‌تر می‌کنند.
می‌توانید با قرار دادن آرگومان درون علامت نقل‌قول، آرگومان‌ها را با استفاده از فاصله به عنوان جداکننده به \f[CR]\-XX:CompileCommand\f[R] ارسال کنید:
.RS
.PP
\f[CR]\-XX:CompileCommand=\(dqexclude java/lang/String indexOf\(dq\f[R]
.RE
توجه داشته باشید که پس از تجزیه دستورات ارسال‌شده در خط فرمان با استفاده از گزینه‌های \f[CR]\-XX:CompileCommand\f[R]، کامپایلر JIT سپس دستورات را از فایل \f[CR].hotspot_compiler\f[R] می‌خواند.
می‌توانید دستوراتی را به این فایل اضافه کنید یا با استفاده از گزینه \f[CR]\-XX:CompileCommandFile\f[R] فایل دیگری را مشخص کنید.
برای افزودن چند دستور، یا گزینه \f[CR]\-XX:CompileCommand\f[R] را چندین بار مشخص کنید، یا هر آرگومان را با جداکننده خط جدید (\f[CR]\(rsn\f[R]) جدا نمایید.
دستورهای زیر در دسترس هستند:
.TP
\f[CR]break\f[R]
هنگام اشکال‌زدایی JVM یک نقطه توقف (breakpoint) تعیین می‌کند تا در آغاز کامپایل متد مشخص‌شده متوقف شود..TP
\f[CR]compileonly\f[R]
تمام متدها را به جز متد مشخص‌شده از کامپایل مستثنی می‌کند.
به عنوان یک جایگزین، می‌توانید از گزینهٔ \f[CR]\-XX:CompileOnly\f[R] استفاده کنید
که امکان تعیین چندین متد را فراهم می‌سازد.
.TP
\f[CR]dontinline\f[R]
از درون‌خطی‌سازی (inlining) متد مشخص‌شده جلوگیری می‌کند.
.TP
\f[CR]exclude\f[R]
متد مشخص‌شده را از کامپایل مستثنی می‌کند.
.TP
\f[CR]help\f[R]
یک پیام راهنما برای گزینهٔ \f[CR]\-XX:CompileCommand\f[R] چاپ می‌کند.
.TP
\f[CR]inline\f[R]
تلاش می‌کند متد مشخص‌شده را درون‌خطی‌سازی کند.
.TP
\f[CR]log\f[R]
ثبت وقایع کامپایل را (با گزینهٔ \f[CR]\-XX:+LogCompilation\f[R])
برای تمام متدها به جز متد مشخص‌شده مستثنی می‌کند.
به‌طور پیش‌فرض، ثبت وقایع برای تمام متدهای کامپایل‌شده انجام می‌شود.
.TP
\f[CR]option\f[R]
یک گزینهٔ کامپایل JIT را به جای آخرین آرگومان (\f[CR]option\f[R]) به متد مشخص‌شده ارسال می‌کند.
گزینهٔ کامپایل در انتها، پس از نام متد تنظیم می‌شود.
برای نمونه، جهت فعال‌سازی گزینهٔ \f[CR]BlockLayoutByFrequency\f[R] برای متد
\f[CR]append()\f[R] از کلاس \f[CR]StringBuffer\f[R]، از دستور زیر استفاده کنید:
.RS
.RS
.PP
\f[CR]\-XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency\f[R]
.RE
می‌توانید چندین گزینهٔ کامپایل را با کاما یا فاصله از یکدیگر جدا کرده و مشخص کنید.
.RE
.TP
\f[CR]print\f[R]
کد اسمبلی ایجادشده را پس از کامپایل متد مشخص‌شده چاپ می‌کند.
.TP
\f[CR]quiet\f[R]
دستور می‌دهد که دستورهای کامپایل چاپ نشوند.
به‌طور پیش‌فرض، دستورهایی که با گزینهٔ \f[CR]\-XX:CompileCommand\f[R]
مشخص می‌کنید چاپ می‌شوند؛ برای نمونه، اگر متد \f[CR]indexOf()\f[R] از کلاس
\f[CR]String\f[R] را از کامپایل مستثنی کنید، عبارت زیر در خروجی استاندارد
چاپ می‌شود:
.RS
.RS
.PP
\f[CR]CompilerOracle: exclude java/lang/String.indexOf\f[R]
.RE
می‌توانید با مشخص کردن گزینهٔ \f[CR]\-XX:CompileCommand=quiet\f[R] پیش از سایر
گزینه‌های \f[CR]\-XX:CompileCommand\f[R]، جلوی این چاپ را بگیرید.
.RE
.RE
.TP
\f[CR]\-XX:CompileCommandFile=\f[R]\f[I]filename\f[R]
فایلی را تنظیم می‌کند که دستورهای کامپایلر JIT از آن خوانده می‌شوند.
به‌طور پیش‌فرض، فایل \f[CR].hotspot_compiler\f[R] برای ذخیرهٔ دستورهای
اجراشده توسط کامپایلر JIT استفاده می‌شود.
.RS
هر خط در فایل دستورها بیانگر یک دستور، نام یک کلاس، و نام یک متد است
که دستور برای آن اعمال می‌شود.
برای نمونه، این خط کد اسمبلی را برای متد \f[CR]toString()\f[R] از کلاس
\f[CR]String\f[R] چاپ می‌کند:
.RS
.PP
\f[CR]print java/lang/String toString\f[R]
.RE
اگر از دستورهایی برای اجرای کامپایلر JIT روی متدها استفاده می‌کنید،
گزینهٔ \f[CR]\-XX:CompileCommand\f[R] را ببینید.
.RE
.TP
\f[CR]\-XX:CompilerDirectivesFile=\f[R]\f[I]file\f[R]
هنگام شروع برنامه، رهنمودها (directives) را از یک فایل به پشتهٔ رهنمودها اضافه می‌کند.
بخش \f[B]Compiler Control\f[R] را ببینید:
[https://docs.oracle.com/en/java/javase/12/vm/compiler\-control1.html#GUID\-94AD8194\-786A\-4F19\-BFFF\-278F8E237F3A].
.RS
گزینهٔ \f[CR]\-XX:CompilerDirectivesFile\f[R] باید همراه با گزینهٔ
\f[CR]\-XX:UnlockDiagnosticVMOptions\f[R] که گزینه‌های عیب‌یابی JVM را
فعال می‌سازد، استفاده شود.
.RE
.TP
\f[CR]\-XX:+CompilerDirectivesPrint\f[R]
هنگام شروع برنامه یا هنگام افزوده‌شدن یک رهنمود جدید، پشتهٔ رهنمودها را چاپ می‌کند.
.RS
گزینهٔ \f[CR]\-XX:+CompilerDirectivesPrint\f[R] باید همراه با گزینهٔ
\f[CR]\-XX:UnlockDiagnosticVMOptions\f[R] که گزینه‌های عیب‌یابی JVM را
فعال می‌سازد، استفاده شود.
.RE
.TP
\f[CR]\-XX:CompileOnly=\f[R]\f[I]methods\f[R]
فهرستی از متدها (جداشده با کاما) را تعیین می‌کند که کامپایل باید به آن‌ها محدود شود.
تنها متدهای مشخص‌شده کامپایل می‌شوند.
.RS
دستور \f[CR]\-XX:CompileOnly=method1,method2,...,methodN\f[R] یک نام مستعار برای دستور زیر است:
.IP
.EX
\-XX:CompileCommand=compileonly,method1
\-XX:CompileCommand=compileonly,method2
\&...
\-XX:CompileCommand=compileonly,methodN
.EE
.RE
.TP
\f[CR]\-XX:CompileThresholdScaling=\f[R]\f[I]scale\f[R]
کنترل یکپارچه‌ای را برای نخستین کامپایل فراهم می‌کند.
این گزینه زمان نخستین کامپایل متدها را برای هر دو حالت لایه‌ای (tiered) و
غیرلایه‌ای (nontiered) کنترل می‌کند.
گزینهٔ \f[CR]CompileThresholdScaling\f[R] مقداری با ممیز شناور بین 0 و Inf+ دارد
و آستانه‌های متناظر با حالت عملیاتی کنونی (هم لایه‌ای و هم غیرلایه‌ای) را مقیاس‌بندی می‌کند.
تنظیم \f[CR]CompileThresholdScaling\f[R] روی مقداری کمتر از 1.0 منجر به
کامپایل زودهنگام‌تر می‌شود، در حالی که مقادیر بزرگ‌تر از 1.0 کامپایل را به تعویق می‌اندازند.
تنظیم \f[CR]CompileThresholdScaling\f[R] روی 0 معادل غیرفعال کردن کامپایل است.
.TP
\f[CR]\-XX:+DoEscapeAnalysis\f[R]
استفاده از تحلیل گریز (escape analysis) را فعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
برای غیرفعال کردن استفاده از تحلیل گریز، گزینهٔ \f[CR]\-XX:\-DoEscapeAnalysis\f[R] را مشخص کنید.
.TP
\f[CR]\-XX:InitialCodeCacheSize=\f[R]\f[I]size\f[R]
اندازهٔ اولیهٔ حافظهٔ پنهان کد (code cache) را (بر حسب بایت) تعیین می‌کند.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای تعیین کیلوبایت،
\f[CR]m\f[R] یا \f[CR]M\f[R] را برای تعیین مگابایت، یا \f[CR]g\f[R] یا
\f[CR]G\f[R] را برای تعیین گیگابایت به انتها اضافه کنید.
مقدار پیش‌فرض به پلتفرم بستگی دارد.
اندازهٔ اولیهٔ حافظهٔ پنهان کد نباید کمتر از کمینهٔ اندازهٔ صفحهٔ حافظهٔ سیستم باشد.
مثال زیر نحوهٔ تنظیم اندازهٔ اولیهٔ حافظهٔ پنهان کد را روی ۳۲ کیلوبایت نشان می‌دهد:
.RS
.RS
.PP
\f[CR]\-XX:InitialCodeCacheSize=32k\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+Inline\f[R]
درون‌خطی‌سازی متدها (method inlining) را فعال می‌کند.
این گزینه به‌طور پیش‌فرض جهت افزایش کارایی فعال است.
برای غیرفعال کردن درون‌خطی‌سازی متدها، \f[CR]\-XX:\-Inline\f[R] را مشخص کنید.
.TP
\f[CR]\-XX:InlineSmallCode=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ کد (بر حسب بایت) را برای متدهای از قبل کامپایل‌شده‌ای که ممکن است
درون‌خطی شوند، تنظیم می‌کند.
این پرچم تنها برای کامپایلر C2 اعمال می‌شود.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای تعیین کیلوبایت،
\f[CR]m\f[R] یا \f[CR]M\f[R] را برای تعیین مگابایت، یا \f[CR]g\f[R] یا
\f[CR]G\f[R] را برای تعیین گیگابایت به انتها اضافه کنید.
مقدار پیش‌فرض به پلتفرم و این‌که آیا کامپایل لایه‌ای فعال است یا خیر، بستگی دارد.
در مثال زیر مقدار آن روی ۱۰۰۰ بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:InlineSmallCode=1000\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+LogCompilation\f[R]
ثبت وقایع فعالیت‌های کامپایل را در فایلی با نام \f[CR]hotspot.log\f[R]
در دایرکتوری کاری فعلی فعال می‌کند.
می‌توانید با استفاده از گزینهٔ \f[CR]\-XX:LogFile\f[R]، مسیر و نام فایل لاگ متفاوتی
را مشخص کنید.
.RS
به‌طور پیش‌فرض، این گزینه غیرفعال است و فعالیت‌های کامپایل ثبت نمی‌شوند.
گزینهٔ \f[CR]\-XX:+LogCompilation\f[R] باید همراه با گزینهٔ
\f[CR]\-XX:UnlockDiagnosticVMOptions\f[R] که گزینه‌های عیب‌یابی JVM را
فعال می‌سازد، استفاده شود.
می‌توانید خروجی عیب‌یابی مشروح (verbose) را با استفاده از گزینهٔ
\f[CR]\-XX:+PrintCompilation\f[R] فعال کنید تا هر بار که متدی کامپایل می‌شود،
پیامی در کنسول چاپ شود.
.RE.TP
\f[CR]\-XX:FreqInlineSize=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ بایت‌کد (به بایت) یک متد پرتکرار (hot method) را برای درون‌خطی‌سازی (inlining) تنظیم می‌کند.
این پرچم تنها روی کامپایلر C2 اعمال می‌شود.
برای مشخص کردن کیلوبایت حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت حرف \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت حرف \f[CR]g\f[R] یا \f[CR]G\f[R] را به انتها اضافه کنید.
مقدار پیش‌فرض به سکو (platform) بستگی دارد.
در مثال زیر روی ۳۲۵ بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:FreqInlineSize=325\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxInlineSize=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ بایت‌کد (به بایت) یک متد کم‌تکرار (cold method) را برای درون‌خطی‌سازی تنظیم می‌کند.
این پرچم تنها روی کامپایلر C2 اعمال می‌شود.
برای مشخص کردن کیلوبایت حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت حرف \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت حرف \f[CR]g\f[R] یا \f[CR]G\f[R] را به انتها اضافه کنید.
به‌طور پیش‌فرض، حداکثر اندازهٔ بایت‌کد روی ۳۵ بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:MaxInlineSize=35\f[R]
.RE
.RE
.TP
\f[CR]\-XX:C1MaxInlineSize=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ بایت‌کد (به بایت) یک متد کم‌تکرار را برای درون‌خطی‌سازی تنظیم می‌کند.
این پرچم تنها روی کامپایلر C1 اعمال می‌شود.
برای مشخص کردن کیلوبایت حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت حرف \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت حرف \f[CR]g\f[R] یا \f[CR]G\f[R] را به انتها اضافه کنید.
به‌طور پیش‌فرض، حداکثر اندازهٔ بایت‌کد روی ۳۵ بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:MaxInlineSize=35\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxTrivialSize=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ بایت‌کد (به بایت) یک متد بدیهی (trivial method) را برای درون‌خطی‌سازی تنظیم می‌کند.
این پرچم تنها روی کامپایلر C2 اعمال می‌شود.
برای مشخص کردن کیلوبایت حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت حرف \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت حرف \f[CR]g\f[R] یا \f[CR]G\f[R] را به انتها اضافه کنید.
به‌طور پیش‌فرض، حداکثر اندازهٔ بایت‌کد یک متد بدیهی روی ۶ بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:MaxTrivialSize=6\f[R]
.RE
.RE
.TP
\f[CR]\-XX:C1MaxTrivialSize=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ بایت‌کد (به بایت) یک متد بدیهی را برای درون‌خطی‌سازی تنظیم می‌کند.
این پرچم تنها روی کامپایلر C1 اعمال می‌شود.
برای مشخص کردن کیلوبایت حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت حرف \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت حرف \f[CR]g\f[R] یا \f[CR]G\f[R] را به انتها اضافه کنید.
به‌طور پیش‌فرض، حداکثر اندازهٔ بایت‌کد یک متد بدیهی روی ۶ بایت تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:MaxTrivialSize=6\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxNodeLimit=\f[R]\f[I]nodes\f[R]
حداکثر تعداد گره‌های مورد استفاده در حین کامپایل یک تک‌متد را تنظیم می‌کند.
به‌طور پیش‌فرض این مقدار به قابلیت‌های فعال‌شده بستگی دارد.
در مثال زیر، حداکثر تعداد گره‌ها روی ۱۰۰٬۰۰۰ تنظیم شده است:
.RS
.RS
.PP
\f[CR]\-XX:MaxNodeLimit=100000\f[R]
.RE
.RE
.TP
\f[CR]\-XX:NonNMethodCodeHeapSize=\f[R]\f[I]size\f[R]
اندازهٔ بخش کد حاوی کدهای غیرمتد (nonmethod code) را به بایت تنظیم می‌کند.
.RS
بخش کد غیرمتد شامل کدهایی مانند بافرهای کامپایلر و مفسر بایت‌کد است.
این نوع کد برای همیشه در حافظهٔ نهان کد (code cache) باقی می‌ماند.
این پرچم تنها در صورتی استفاده می‌شود که \f[CR]\-XX:SegmentedCodeCache\f[R] فعال باشد.
.RE
.TP
\f[CR]\-XX:NonProfiledCodeHeapSize=\f[R]\f[I]size\f[R]
اندازهٔ بخش کد حاوی متدهای پروفایل‌نشده را به بایت تنظیم می‌کند.
این پرچم تنها در صورتی استفاده می‌شود که \f[CR]\-XX:SegmentedCodeCache\f[R] فعال باشد.
.TP
\f[CR]\-XX:+OptimizeStringConcat\f[R]
بهینه‌سازی عملیات الحاق رشته‌های \f[CR]String\f[R] را فعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
برای غیرفعال کردن بهینه‌سازی عملیات الحاق رشته‌های \f[CR]String\f[R]، پرچم \f[CR]\-XX:\-OptimizeStringConcat\f[R] را مشخص کنید.
.TP
\f[CR]\-XX:+PrintAssembly\f[R]
چاپ کد اسمبلی متدهای بایت‌کدی و بومی (native) را با استفاده از کتابخانهٔ خارجی \f[CR]hsdis\-<arch>.so\f[R] یا \f[CR].dll\f[R] فعال می‌کند.
برای ماشین مجازی ۶۴ بیتی در Windows، این کتابخانه \f[CR]hsdis\-amd64.dll\f[R] است.
این گزینه امکان مشاهدهٔ کد تولیدشده را فراهم می‌سازد که می‌تواند به عیب‌یابی مسائل کارایی کمک کند.
.RS
به‌طور پیش‌فرض، این گزینه غیرفعال است و کد اسمبلی چاپ نمی‌شود.
گزینهٔ \f[CR]\-XX:+PrintAssembly\f[R] باید همراه با گزینهٔ \f[CR]\-XX:UnlockDiagnosticVMOptions\f[R] (که گزینه‌های عیب‌یابی JVM را فعال می‌کند) استفاده شود.
.RE
.TP
\f[CR]\-XX:ProfiledCodeHeapSize=\f[R]\f[I]size\f[R]
اندازهٔ بخش کد حاوی متدهای پروفایل‌شده را به بایت تنظیم می‌کند.
این پرچم تنها در صورتی استفاده می‌شود که \f[CR]\-XX:SegmentedCodeCache\f[R] فعال باشد.
.TP
\f[CR]\-XX:+PrintCompilation\f[R]
خروجی عیب‌یابی مشروح را از JVM با چاپ یک پیام در کنسول در هر بار کامپایل شدن یک متد فعال می‌کند.
این گزینه امکان می‌دهد ببینید کدام متدها واقعاً کامپایل می‌شوند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و خروجی عیب‌یابی چاپ نمی‌شود.
.RS
همچنین می‌توانید با استفاده از گزینهٔ \f[CR]\-XX:+LogCompilation\f[R] فعالیت کامپایل را در یک فایل ثبت کنید.
.RE
.TP
\f[CR]\-XX:+PrintInlining\f[R]
چاپ تصمیمات مربوط به درون‌خطی‌سازی را فعال می‌کند.
این گزینه امکان می‌دهد ببینید کدام متدها در حال درون‌خطی شدن هستند.
.RS
به‌طور پیش‌فرض، این گزینه غیرفعال است و اطلاعات درون‌خطی‌سازی چاپ نمی‌شود.
گزینهٔ \f[CR]\-XX:+PrintInlining\f[R] باید همراه با گزینهٔ \f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] (که گزینه‌های عیب‌یابی JVM را فعال می‌کند) استفاده شود.
.RE
.TP
\f[CR]\-XX:ReservedCodeCacheSize=\f[R]\f[I]size\f[R]
حداکثر اندازهٔ حافظهٔ نهان کد (code cache) را به بایت برای کدهای کامپایل‌شده توسط JIT تنظیم می‌کند.
برای مشخص کردن کیلوبایت حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای مگابایت حرف \f[CR]m\f[R] یا \f[CR]M\f[R]، و برای گیگابایت حرف \f[CR]g\f[R] یا \f[CR]G\f[R] را به انتها اضافه کنید.
حداکثر اندازهٔ پیش‌فرض حافظهٔ نهان کد ۲۴۰ مگابایت است؛ اگر کامپایل لایه‌ای (tiered compilation) را با گزینهٔ \f[CR]\-XX:\-TieredCompilation\f[R] غیرفعال کنید، اندازهٔ پیش‌فرض ۴۸ مگابایت خواهد بود.
این گزینه دارای محدودیت ۲ گیگابایت است؛ در غیر این صورت یک خطا ایجاد می‌شود.
حداکثر اندازهٔ حافظهٔ نهان کد نباید از اندازهٔ اولیهٔ آن کمتر باشد؛ گزینهٔ \f[CR]\-XX:InitialCodeCacheSize\f[R] را ببینید.
.TP
\f[CR]\-XX:+SegmentedCodeCache\f[R]
بخش‌بندی حافظهٔ نهان کد را فعال می‌کند، که بدون آن، حافظهٔ نهان کد تنها شامل یک بخش بزرگ است.
با استفاده از \f[CR]\-XX:+SegmentedCodeCache\f[R]، بخش‌های جداگانه‌ای برای کدهای غیرمتد، متدهای پروفایل‌شده، و متدهای پروفایل‌نشده در نظر گرفته می‌شود.
اندازهٔ بخش‌ها در زمان اجرا تغییر نمی‌کند.
مزایای آن شامل کنترل بهتر بر ردپای حافظه (memory footprint)، کاهش تکه‌تکه‌شدگی کد (fragmentation)، و بهبود رفتار iTLB (instruction translation lookaside buffer) پردازنده و حافظهٔ نهان دستورالعمل به دلیل بهبود محلی‌سازی (locality) است.
.RS
این قابلیت در صورتی که کامپایل لایه‌ای فعال باشد (\f[CR]\-XX:+TieredCompilation\f[R]) و اندازهٔ حافظهٔ نهان کد رزروشده (\f[CR]\-XX:ReservedCodeCacheSize\f[R]) حداقل ۲۴۰ مگابایت باشد، به‌طور پیش‌فرض فعال است.
.RE
.TP
\f[CR]\-XX:StartAggressiveSweepingAt=\f[R]\f[I]percent\f[R]
پیمایش پشتهٔ (stack scanning) متدهای فعال را مجبور می‌کند تا زمانی که تنها درصد مشخص‌شده‌ای از حافظهٔ نهان کد آزاد است، کدهای بدون استفاده را به‌طور تهاجمی پاکسازی کند.
مقدار پیش‌فرض ۱۰٪ است..TP
\f[CR]\-XX:\-TieredCompilation\f[R]
استفاده از کامپایل چندلایه‌ای (tiered compilation) را غیرفعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
.TP
\f[CR]\-XX:UseSSE=\f[R]\f[I]version\f[R]
استفاده از مجموعه دستورالعمل‌های SSE از یک نسخه مشخص را فعال می‌کند.
به‌طور پیش‌فرض روی بالاترین نسخه پشتیبانی‌شده موجود تنظیم می‌شود (فقط x86).
.TP
\f[CR]\-XX:UseAVX=\f[R]\f[I]version\f[R]
استفاده از مجموعه دستورالعمل‌های AVX از یک نسخه مشخص را فعال می‌کند.
به‌طور پیش‌فرض روی بالاترین نسخه پشتیبانی‌شده موجود تنظیم می‌شود (فقط x86).
.TP
\f[CR]\-XX:+UseAES\f[R]
اینترینسیک‌های مبتنی بر سخت‌افزار AES را برای سخت‌افزارهایی که از آن پشتیبانی می‌کنند فعال می‌کند.
این گزینه به‌طور پیش‌فرض روی سخت‌افزارهایی که دستورالعمل‌های لازم را دارند روشن است.
گزینه \f[CR]\-XX:+UseAES\f[R] همراه با \f[CR]UseAESIntrinsics\f[R] استفاده می‌شود.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseAESIntrinsics\f[R]
اینترینسیک‌های AES را فعال می‌کند.
مشخص کردن \f[CR]\-XX:+UseAESIntrinsics\f[R] معادل فعال‌سازی هم‌زمان \f[CR]\-XX:+UseAES\f[R] نیز می‌باشد.
برای غیرفعال کردن اینترینسیک‌های سخت‌افزاری AES، عبارت
\f[CR]\-XX:\-UseAES \-XX:\-UseAESIntrinsics\f[R] را مشخص کنید.
برای مثال، جهت فعال‌سازی AES سخت‌افزاری، از پرچم‌های زیر استفاده کنید:
.RS
.RS
.PP
\f[CR]\-XX:+UseAES \-XX:+UseAESIntrinsics\f[R]
.RE
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.RE
.TP
\f[CR]\-XX:+UseAESCTRIntrinsics\f[R]
مشابه با \f[CR]\-XX:+UseAESIntrinsics\f[R]، اینترینسیک‌های AES/CTR را فعال می‌کند.
.TP
\f[CR]\-XX:+UseGHASHIntrinsics\f[R]
استفاده از اینترینسیک‌های GHASH را کنترل می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از دستورالعمل‌های مربوطه پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseChaCha20Intrinsics\f[R]
اینترینسیک‌های ChaCha20 را فعال می‌کند.
این گزینه به‌طور پیش‌فرض برای پلتفرم‌های پشتیبانی‌شده فعال است.
برای غیرفعال‌سازی اینترینسیک‌های ChaCha20، گزینه
\f[CR]\-XX:\-UseChaCha20Intrinsics\f[R] را مشخص کنید.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UsePoly1305Intrinsics\f[R]
اینترینسیک‌های Poly1305 را فعال می‌کند.
این گزینه به‌طور پیش‌فرض برای پلتفرم‌های پشتیبانی‌شده فعال است.
برای غیرفعال‌سازی اینترینسیک‌های Poly1305، گزینه
\f[CR]\-XX:\-UsePoly1305Intrinsics\f[R] را مشخص کنید.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseBASE64Intrinsics\f[R]
استفاده از روال‌های شتاب‌یافته رمزگذاری BASE64 را برای
\f[CR]java.util.Base64\f[R] کنترل می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseAdler32Intrinsics\f[R]
استفاده از اینترینسیک الگوریتم چکسام Adler32 را برای
\f[CR]java.util.zip.Adler32\f[R] کنترل می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseCRC32Intrinsics\f[R]
استفاده از اینترینسیک‌های CRC32 را برای \f[CR]java.util.zip.CRC32\f[R] کنترل می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseCRC32CIntrinsics\f[R]
استفاده از اینترینسیک‌های CRC32C را برای
\f[CR]java.util.zip.CRC32C\f[R] کنترل می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseSHA\f[R]
اینترینسیک‌های مبتنی بر سخت‌افزار را برای توابع درهم‌سازی رمزنگاری SHA در برخی سخت‌افزارها فعال می‌کند.
گزینه \f[CR]UseSHA\f[R] همراه با گزینه‌های
\f[CR]UseSHA1Intrinsics\f[R]، \f[CR]UseSHA256Intrinsics\f[R] و
\f[CR]UseSHA512Intrinsics\f[R] استفاده می‌شود.
.RS
پرچم‌های \f[CR]UseSHA\f[R] و \f[CR]UseSHA*Intrinsics\f[R] به‌طور پیش‌فرض
روی دستگاه‌هایی که از دستورالعمل‌های متناظر پشتیبانی می‌کنند فعال هستند.
این ویژگی تنها هنگام استفاده از ارائه‌دهنده \f[CR]sun.security.provider.Sun\f[R] برای عملیات‌های SHA قابل اجرا است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
جهت غیرفعال‌سازی تمامی اینترینسیک‌های مبتنی بر سخت‌افزار SHA، گزینه \f[CR]\-XX:\-UseSHA\f[R] را مشخص کنید.
برای غیرفعال کردن تنها یک اینترینسیک خاص SHA، از گزینه متناظر مناسب استفاده کنید.
برای مثال: \f[CR]\-XX:\-UseSHA256Intrinsics\f[R].
.RE
.TP
\f[CR]\-XX:+UseSHA1Intrinsics\f[R]
اینترینسیک‌ها را برای تابع درهم‌سازی رمزنگاری SHA\-1 فعال می‌کند.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseSHA256Intrinsics\f[R]
اینترینسیک‌ها را برای توابع درهم‌سازی رمزنگاری SHA\-224 و SHA\-256 فعال می‌کند.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseSHA512Intrinsics\f[R]
اینترینسیک‌ها را برای توابع درهم‌سازی رمزنگاری SHA\-384 و SHA\-512 فعال می‌کند.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseMathExactIntrinsics\f[R]
تبدیل توابع مختلف \f[CR]java.lang.Math.*Exact()\f[R] به اینترینسیک را فعال می‌کند.
به‌طور پیش‌فرض فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseMultiplyToLenIntrinsic\f[R]
تبدیل \f[CR]BigInteger.multiplyToLen()\f[R] به اینترینسیک را فعال می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\-XX:+UseSquareToLenIntrinsic
تبدیل \f[CR]BigInteger.squareToLen()\f[R] به اینترینسیک را فعال می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\-XX:+UseMulAddIntrinsic
تبدیل \f[CR]BigInteger.mulAdd()\f[R] به اینترینسیک را فعال می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\-XX:+UseMontgomeryMultiplyIntrinsic
تبدیل \f[CR]BigInteger.montgomeryMultiply()\f[R] به اینترینسیک را فعال می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\-XX:+UseMontgomerySquareIntrinsic
تبدیل \f[CR]BigInteger.montgomerySquare()\f[R] به اینترینسیک را فعال می‌کند.
به‌طور پیش‌فرض روی پلتفرم‌هایی که از آن پشتیبانی می‌کنند فعال است.
پرچم‌هایی که اینترینسیک‌ها را کنترل می‌کنند اکنون نیازمند گزینه
\f[CR]\-XX:+UnlockDiagnosticVMOptions\f[R] هستند.
.TP
\f[CR]\-XX:+UseCMoveUnconditionally\f[R]
دستورالعمل‌های CMove (اسکالر و برداری) را صرف‌نظر از تحلیل سودآوری تولید می‌کند.
.TP
\f[CR]\-XX:+UseCodeCacheFlushing\f[R]
تخلیه حافظه پنهان کد (code cache) را پیش از خاموش شدن کامپایلر فعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
جهت غیرفعال‌سازی تخلیه حافظه پنهان کد پیش از خاموش شدن کامپایلر،
گزینه \f[CR]\-XX:\-UseCodeCacheFlushing\f[R] را مشخص کنید.
.TP
\f[CR]\-XX:+UseCondCardMark\f[R]
بررسی این‌که آیا کارت پیش از به‌روزرسانی جدول کارت از قبل نشانه‌گذاری شده است یا خیر را فعال می‌کند.
این گزینه به‌طور پیش‌فرض غیرفعال است.
این گزینه تنها باید در دستگاه‌های چند سوکته استفاده شود، جایی که عملکرد برنامه‌های جاوای وابسته به عملیات‌های هم‌روند را بهبود می‌بخشد..TP
\f[CR]\-XX:+UseCountedLoopSafepoints\f[R]
نقاط امن (safepoint) را در حلقه‌های شمارشی (counted loops) نگه می‌دارد.
مقدار پیش‌فرض آن به این بستگی دارد که آیا زباله‌روبِ انتخاب‌شده به نقاط امن با تاخیر کم نیاز دارد یا خیر.
.TP
\f[CR]\-XX:LoopStripMiningIter=\f[R]\f[I]number_of_iterations\f[R]
تعداد تکرارها در حلقه داخلی strip mined را کنترل می‌کند.
تکنیک Strip mining حلقه‌های شمارشی را به حلقه‌های تودرتوی دو سطحی تبدیل می‌کند.
نقاط امن در حلقه بیرونی نگه داشته می‌شوند در حالی که حلقه درونی می‌تواند با حداکثر سرعت اجرا شود.
این گزینه حداکثر تعداد تکرارها در حلقه درونی را کنترل می‌کند.
مقدار پیش‌فرض ۱٬۰۰۰ است.
.TP
\f[CR]\-XX:LoopStripMiningIterShortLoop=\f[R]\f[I]number_of_iterations\f[R]
بهینه‌سازی strip mining حلقه را کنترل می‌کند.
حلقه‌هایی با تعداد تکرار کمتر از مقدار مشخص‌شده، نقطه امنی در خود نخواهند داشت.
مقدار پیش‌فرض ۱/۱۰ مقدار \f[CR]\-XX:LoopStripMiningIter\f[R] است.
.TP
\f[CR]\-XX:+UseFMA\f[R]
توابع درونی (intrinsics) سخت‌افزاری FMA را برای سخت‌افزارهایی که دستورالعمل‌های FMA در آن‌ها در دسترس است (مانند Intel و ARM64) فعال می‌کند.
توابع درونی FMA برای متدهای
\f[CR]java.lang.Math.fma(\f[R]\f[I]a\f[R]\f[CR],\f[R]
\f[I]b\f[R]\f[CR],\f[R] \f[I]c\f[R]\f[CR])\f[R] تولید می‌شوند که مقدار عبارت‌های
\f[CR](\f[R] \f[I]a\f[R] \f[CR]*\f[R] \f[I]b\f[R]
\f[CR]+\f[R] \f[I]c\f[R] \f[CR])\f[R] را محاسبه می‌کنند.
.TP
\f[CR]\-XX:+UseSuperWord\f[R]
تبدیل عملیات اسکالر (scalar) به عملیات superword را فعال می‌کند.
روش Superword یک بهینه‌سازی برداری‌سازی (vectorization) است.
این گزینه به صورت پیش‌فرض فعال است.
برای غیرفعال کردن تبدیل عملیات اسکالر به عملیات superword، مقدار \f[CR]\-XX:\-UseSuperWord\f[R] را مشخص کنید.
.SH "گزینه‌های پیشرفته سرویس‌پذیری برای جاوا (ADVANCED SERVICEABILITY OPTIONS FOR JAVA)"
این گزینه‌های \f[CR]java\f[R] امکان جمع‌آوری اطلاعات سیستم و انجام اشکال‌زدایی گسترده را فراهم می‌کنند.
.TP
\f[CR]\-XX:+DisableAttachMechanism\f[R]
مکانیزمی را که به ابزارها اجازه اتصال به JVM را می‌دهد، غیرفعال می‌کند.
به طور پیش‌فرض، این گزینه غیرفعال است؛ یعنی مکانیزم اتصال فعال بوده و می‌توانید از ابزارهای تشخیصی و عیب‌یابی مانند
\f[CR]jcmd\f[R]، \f[CR]jstack\f[R]، \f[CR]jmap\f[R] و
\f[CR]jinfo\f[R] استفاده کنید.
.RS
.RS
.PP
\f[B]نکته:\f[R] ابزارهایی مانند \f[B]jcmd\f[R]، \f[B]jinfo\f[R]،
\f[B]jmap\f[R] و \f[B]jstack\f[R] که همراه با JDK عرضه می‌شوند، در صورت استفاده برای عیب‌یابی نسخه‌ای متفاوت از JDK پشتیبانی نمی‌شوند.
.RE
.RE
.TP
\f[CR]\-XX:+DTraceAllocProbes\f[R]
\f[B]لینوکس و macOS:\f[R] کاوشگرهای ابزار \f[CR]dtrace\f[R] را برای تخصیص شیء فعال می‌کند.
.TP
\f[CR]\-XX:+DTraceMethodProbes\f[R]
\f[B]لینوکس و macOS:\f[R] کاوشگرهای ابزار \f[CR]dtrace\f[R] را برای ورود به متد و خروج از متد فعال می‌کند.
.TP
\f[CR]\-XX:+DTraceMonitorProbes\f[R]
\f[B]لینوکس و macOS:\f[R] کاوشگرهای ابزار \f[CR]dtrace\f[R] را برای رویدادهای مانیتور (monitor events) فعال می‌کند.
.TP
\f[CR]\-XX:+HeapDumpOnOutOfMemoryError\f[R]
تخلیه هیپ جاوا به یک فایل در دایرکتوری جاری با استفاده از نمایه‌ساز هیپ (HPROF) را در زمان پرتاب استثنای
\f[CR]java.lang.OutOfMemoryError\f[R] توسط JVM فعال می‌کند.
می‌توانید مسیر و نام فایل تخلیه هیپ را با استفاده از گزینه
\f[CR]\-XX:HeapDumpPath\f[R] به صورت صریح تعیین کنید.
به طور پیش‌فرض، این گزینه غیرفعال است و هنگام پرتاب استثنای
\f[CR]OutOfMemoryError\f[R] هیپ تخلیه نمی‌شود.
این ویژگی تنها برای استثناهای \f[CR]OutOfMemoryError\f[R] ناشی از اتمام حافظه هیپ جاوا اعمال می‌شود؛ این گزینه برای استثناهای \f[CR]OutOfMemoryError\f[R] که مستقیماً از کد جاوا پرتاب می‌شوند، یا توسط JVM برای سایر انواع اتمام منابع (مانند خطاهای ایجاد ریسه بومی) رخ می‌دهند، اعمال نخواهد شد.
.TP
\f[CR]\-XX:HeapDumpPath=\f[R]\f[I]path\f[R]
مسیر و نام فایل را برای نوشتن تخلیه هیپ ارائه‌شده توسط نمایه‌ساز هیپ (HPROF) هنگام تنظیم بودن گزینه
\f[CR]\-XX:+HeapDumpOnOutOfMemoryError\f[R] تعیین می‌کند.
به طور پیش‌فرض، فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن
\f[CR]java_pid<pid>.hprof\f[R] است که در آن \f[CR]<pid>\f[R] شناسه فرایندی است که موجب بروز خطا شده است.
مثال زیر نحوه تعیین صریح فایل پیش‌فرض را نشان می‌دهد
(\f[CR]%p\f[R] بیانگر شناسه فرایند فعلی است):
.RS
.RS
.PP
\f[CR]\-XX:HeapDumpPath=./java_pid%p.hprof\f[R]
.RE
.IP \(bu 2
\f[B]غیر ویندوز:\f[R] مثال زیر نحوه تنظیم فایل تخلیه هیپ روی \f[CR]/var/log/java/java_heapdump.hprof\f[R] را نشان می‌دهد:
.RS 2
.RS
.PP
\f[CR]\-XX:HeapDumpPath=/var/log/java/java_heapdump.hprof\f[R]
.RE
.RE
.IP \(bu 2
\f[B]ویندوز:\f[R] مثال زیر نحوه تنظیم فایل تخلیه هیپ روی \f[CR]C:/log/java/java_heapdump.log\f[R] را نشان می‌دهد:
.RS 2
.RS
.PP
\f[CR]\-XX:HeapDumpPath=C:/log/java/java_heapdump.log\f[R]
.RE
.RE
.RE
.TP
\f[CR]\-XX:LogFile=\f[R]\f[I]path\f[R]
مسیر و نام فایل را برای محل نوشتن داده‌های گزارش وقایع (log) تعیین می‌کند.
به طور پیش‌فرض، فایل در دایرکتوری کاری جاری ایجاد می‌شود و نام آن
\f[CR]hotspot.log\f[R] است.
.RS
.IP \(bu 2
\f[B]غیر ویندوز:\f[R] مثال زیر نحوه تنظیم فایل گزارش وقایع روی \f[CR]/var/log/java/hotspot.log\f[R] را نشان می‌دهد:
.RS 2
.RS
.PP
\f[CR]\-XX:LogFile=/var/log/java/hotspot.log\f[R]
.RE
.RE
.IP \(bu 2
\f[B]ویندوز:\f[R] مثال زیر نحوه تنظیم فایل گزارش وقایع روی \f[CR]C:/log/java/hotspot.log\f[R] را نشان می‌دهد:
.RS 2
.RS
.PP
\f[CR]\-XX:LogFile=C:/log/java/hotspot.log\f[R]
.RE
.RE
.RE
.TP
\f[CR]\-XX:+PrintClassHistogram\f[R]
چاپ بافت‌نگار (هیستوگرام) نمونه‌های کلاس را پس از یکی از رویدادهای زیر فعال می‌کند:
.RS
.IP \(bu 2
\f[B]غیر ویندوز:\f[R] \f[CR]Control+\(rs\f[R] (\f[CR]SIGQUIT\f[R])
.IP \(bu 2
\f[B]ویندوز:\f[R] \f[CR]Control+C\f[R] (\f[CR]SIGTERM\f[R])
به طور پیش‌فرض، این گزینه غیرفعال است.
تنظیم این گزینه معادل با اجرای دستور \f[CR]jmap \-histo\f[R] یا دستور
\f[CR]jcmd\f[R] \f[I]pid\f[R] \f[CR]GC.class_histogram\f[R] است که در آن
\f[I]pid\f[R] شناسه فرایند فعلی جاوا است.
.RE
.TP
\f[CR]\-XX:+PrintConcurrentLocks\f[R]
چاپ قفل‌های \f[CR]java.util.concurrent\f[R] را پس از یکی از رویدادهای زیر فعال می‌کند:
.RS
.IP \(bu 2
\f[B]غیر ویندوز:\f[R] \f[CR]Control+\(rs\f[R] (\f[CR]SIGQUIT\f[R])
.IP \(bu 2
\f[B]ویندوز:\f[R] \f[CR]Control+C\f[R] (\f[CR]SIGTERM\f[R])
به طور پیش‌فرض، این گزینه غیرفعال است.
تنظیم این گزینه معادل با اجرای دستور \f[CR]jstack \-l\f[R] یا دستور
\f[CR]jcmd\f[R] \f[I]pid\f[R] \f[CR]Thread.print \-l\f[R] است که در آن
\f[I]pid\f[R] شناسه فرایند فعلی جاوا است.
.RE
.TP
\f[CR]\-XX:+PrintFlagsRanges\f[R]
محدوده مشخص‌شده را چاپ کرده و امکان آزمایش خودکار مقادیر را فراهم می‌سازد.
بخش \f[B]Validate Java Virtual Machine Flag Arguments\f[R] را ببینید.
.TP
\f[CR]\-XX:+PerfDataSaveToFile\f[R]
در صورت فعال بودن، داده‌های دودویی (binary) ابزار \f[B]jstat\f[R] را هنگام خروج برنامه جاوا ذخیره می‌کند.
این داده‌های دودویی در فایلی با نام
\f[CR]hsperfdata_\f[R]\f[I]pid\f[R] ذخیره می‌شوند که در آن \f[I]pid\f[R] شناسه فرایند برنامه جاوای اجراشده توسط شما است.
برای نمایش داده‌های کارایی موجود در این فایل، از دستور \f[CR]jstat\f[R] به صورت زیر استفاده کنید:
.RS
.RS.PP
\f[CR]jstat \-class file:///\f[R]\f[I]path\f[R]\f[CR]/hsperfdata_\f[R]\f[I]pid\f[R]
.RE
.RS
.PP
\f[CR]jstat \-gc file:///\f[R]\f[I]path\f[R]\f[CR]/hsperfdata_\f[R]\f[I]pid\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+UsePerfData\f[R]
ویژگی \f[CR]perfdata\f[R] را فعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است تا امکان نظارت بر JVM و
آزمون کارایی فراهم باشد.
غیرفعال کردن آن از ایجاد دایرکتوری‌های \f[CR]hsperfdata_userid\f[R]
جلوگیری می‌کند.
برای غیرفعال کردن ویژگی \f[CR]perfdata\f[R]،
\f[CR]\-XX:\-UsePerfData\f[R] را مشخص کنید.
.SH "گزینه‌های پیشرفته بازیافت حافظه برای جاوا (ADVANCED GARBAGE COLLECTION OPTIONS FOR JAVA)"
این گزینه‌های \f[CR]java\f[R] نحوه انجام بازیافت حافظه (GC) را
توسط Java HotSpot VM کنترل می‌کنند.
.TP
\f[CR]\-XX:+AlwaysPreTouch\f[R]
از VM درخواست می‌کند که پس از درخواست هر صفحه در هیپ جاوا از سیستم‌عامل
و پیش از تحویل دادن حافظه به برنامه، آن صفحه را لمس (pre-touch) کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و همه صفحات هم‌زمان با
استفاده برنامه از فضای هیپ، تخصیص قطعی می‌یابند.
.TP
\f[CR]\-XX:ConcGCThreads=\f[R]\f[I]threads\f[R]
تعداد رشته‌های مورداستفاده برای بازیافت حافظه هم‌روند را تنظیم می‌کند.
مقدار \f[I]\f[CI]threads\f[I]\f[R] را تقریباً روی ۱/۴ تعداد
رشته‌های بازیافت حافظه موازی قرار می‌دهد.
مقدار پیش‌فرض به تعداد پردازنده‌های (CPUs) در دسترس JVM بستگی دارد.
.RS
برای نمونه، جهت تنظیم تعداد رشته‌های GC هم‌روند روی ۲،
گزینه زیر را مشخص کنید:
.RS
.PP
\f[CR]\-XX:ConcGCThreads=2\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+DisableExplicitGC\f[R]
گزینه‌ای را فعال می‌کند که پردازش فراخوانی‌های متد
\f[CR]System.gc()\f[R] را غیرفعال می‌سازد.
این گزینه به‌طور پیش‌فرض غیرفعال است، به این معنی که فراخوانی‌های
\f[CR]System.gc()\f[R] پردازش می‌شوند.
اگر پردازش فراخوانی‌های \f[CR]System.gc()\f[R] غیرفعال باشد،
JVM همچنان در صورت نیاز GC را اجرا خواهد کرد.
.TP
\f[CR]\-XX:+ExplicitGCInvokesConcurrent\f[R]
فراخوانی GC هم‌روند را با استفاده از درخواست
\f[CR]System.gc()\f[R] فعال می‌کند.
این گزینه به‌طور پیش‌فرض غیرفعال است و تنها همراه با
گزینه \f[CR]\-XX:+UseG1GC\f[R] می‌تواند فعال شود.
.TP
\f[CR]\-XX:G1AdaptiveIHOPNumInitialSamples=\f[R]\f[I]number\f[R]
هنگامی که \f[CR]\-XX:UseAdaptiveIHOP\f[R] فعال باشد، این گزینه
تعداد چرخه‌های نشانه‌گذاری تکمیل‌شده‌ای را که برای جمع‌آوری نمونه‌ها استفاده می‌شوند
مشخص می‌کند، تا زمانی که G1 به‌صورت تطبیقی مقدار بهینه
\f[CR]\-XX:InitiatingHeapOccupancyPercent\f[R] را تعیین کند.
پیش از آن، G1 مستقیماً از مقدار
\f[CR]\-XX:InitiatingHeapOccupancyPercent\f[R] برای این منظور
استفاده می‌کند.
مقدار پیش‌فرض ۳ است.
.TP
\f[CR]\-XX:G1HeapRegionSize=\f[R]\f[I]size\f[R]
اندازه ناحیه‌هایی را تعیین می‌کند که در هنگام استفاده از
بازیافت‌کننده G1 (Garbage-First)، هیپ جاوا به آن‌ها تقسیم می‌شود.
این مقدار توانی از ۲ است و می‌تواند در بازه ۱ مگابایت تا ۳۲ مگابایت باشد.
اندازه پیش‌فرض ناحیه به‌صورت ارگونومیک بر پایه اندازه هیپ
و با هدف دستیابی به تقریباً ۲۰۴۸ ناحیه تعیین می‌شود.
.RS
مثال زیر اندازه زیربخش‌ها را روی ۱۶ مگابایت تنظیم می‌کند:
.RS
.PP
\f[CR]\-XX:G1HeapRegionSize=16m\f[R]
.RE
.RE
.TP
\f[CR]\-XX:G1HeapWastePercent=\f[R]\f[I]percent\f[R]
درصدی از هیپ را که مایل به هدررفت آن هستید تعیین می‌کند.
Java HotSpot VM هنگامی که درصد قابل بازپس‌گیری کمتر از درصد
هدررفت هیپ باشد، چرخه بازیافت حافظه ترکیبی (mixed) را آغاز نمی‌کند.
مقدار پیش‌فرض ۵ درصد است.
.TP
\f[CR]\-XX:G1MaxNewSizePercent=\f[R]\f[I]percent\f[R]
درصدی از اندازه هیپ را برای استفاده به‌عنوان بیشینه اندازه
نسل جوان (young generation) تعیین می‌کند.
مقدار پیش‌فرض ۶۰ درصد از هیپ جاوای شما است.
.RS
این یک پرچم آزمایشی است.
این تنظیم جایگزین تنظیم \f[CR]\-XX:DefaultMaxNewGenPercent\f[R]
می‌شود.
.RE
.TP
\f[CR]\-XX:G1MixedGCCountTarget=\f[R]\f[I]number\f[R]
تعداد هدف بازیافت‌های حافظه ترکیبی را پس از یک چرخه نشانه‌گذاری
تنظیم می‌کند تا ناحیه‌های قدیمی با حداکثر داده زنده به میزان
\f[CR]G1MixedGCLIveThresholdPercent\f[R] جمع‌آوری شوند.
مقدار پیش‌فرض ۸ بازیافت حافظه ترکیبی است.
هدف بازیافت‌های ترکیبی این است که در محدوده این تعداد هدف باقی بمانند.
.TP
\f[CR]\-XX:G1MixedGCLiveThresholdPercent=\f[R]\f[I]percent\f[R]
آستانه اشغال یک ناحیه قدیمی را جهت گنجانده شدن در یک چرخه
بازیافت حافظه ترکیبی تعیین می‌کند.
اشغال پیش‌فرض ۸۵ درصد است.
.RS
این یک پرچم آزمایشی است.
این تنظیم جایگزین تنظیم
\f[CR]\-XX:G1OldCSetRegionLiveThresholdPercent\f[R] می‌شود.
.RE
.TP
\f[CR]\-XX:G1NewSizePercent=\f[R]\f[I]percent\f[R]
درصدی از هیپ را برای استفاده به‌عنوان کمینه اندازه
نسل جوان تعیین می‌کند.
مقدار پیش‌فرض ۵ درصد از هیپ جاوای شما است.
.RS
این یک پرچم آزمایشی است.
این تنظیم جایگزین تنظیم \f[CR]\-XX:DefaultMinNewGenPercent\f[R]
می‌شود.
.RE
.TP
\f[CR]\-XX:G1OldCSetRegionThresholdPercent=\f[R]\f[I]percent\f[R]
حد بالایی را برای تعداد ناحیه‌های قدیمی قابل جمع‌آوری در طول یک چرخه
بازیافت حافظه ترکیبی تعیین می‌کند.
مقدار پیش‌فرض ۱۰ درصد از هیپ جاوا است.
.TP
\f[CR]\-XX:G1ReservePercent=\f[R]\f[I]percent\f[R]
درصدی از هیپ (۰ تا ۵۰) را که به‌عنوان یک سقف کاذب برای کاهش
احتمال شکست ارتقا (promotion failure) در بازیافت‌کننده G1
رزرو می‌شود، تعیین می‌کند.
هنگامی که این درصد را افزایش یا کاهش می‌دهید، مطمئن شوید که
کل هیپ جاوا را به همان میزان تنظیم می‌کنید.
به‌طور پیش‌فرض، این گزینه روی ۱۰٪ تنظیم شده است.
.RS
مثال زیر هیپ رزروشده را روی ۲۰٪ تنظیم می‌کند:
.RS
.PP
\f[CR]\-XX:G1ReservePercent=20\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+G1UseAdaptiveIHOP\f[R]
محاسبه تطبیقی میزان اشغال نسل قدیمی را برای شروع کارهای پس‌زمینه
جهت آماده‌سازی بازیافت نسل قدیمی کنترل می‌کند.
در صورت فعال بودن، G1 برای چند بار نخست همان‌طور که با مقدار
\f[CR]\-XX:G1AdaptiveIHOPNumInitialSamples\f[R] مشخص شده، از
\f[CR]\-XX:InitiatingHeapOccupancyPercent\f[R] استفاده می‌کند، و پس از آن
به‌طور خودکار مقدار بهینه جدیدی را برای اشغال اولیه به‌صورت تطبیقی محاسبه می‌نماید.
در غیر این صورت، فرایند بازیافت نسل قدیمی همواره در میزان اشغال
تعیین‌شده توسط \f[CR]\-XX:InitiatingHeapOccupancyPercent\f[R] آغاز می‌شود.
.RS
پیش‌فرض فعال است.
.RE
.TP
\f[CR]\-XX:InitialHeapSize=\f[R]\f[I]size\f[R]
اندازه اولیه (به بایت) مخزن تخصیص حافظه را تنظیم می‌کند.
این مقدار باید ۰ یا مضربی از ۱۰۲۴ و بزرگ‌تر از ۱ مگابایت باشد.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت،
\f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا
\f[CR]G\f[R] را برای گیگابایت اضافه کنید.
مقدار پیش‌فرض در زمان اجرا بر پایه پیکربندی سیستم انتخاب می‌شود.
.RS
مثال‌های زیر نحوه تنظیم اندازه حافظه تخصیص‌یافته به ۶ مگابایت را با
استفاده از واحدهای مختلف نشان می‌دهند:
.IP
.EX
\-XX:InitialHeapSize=6291456
\-XX:InitialHeapSize=6144k
\-XX:InitialHeapSize=6m
.EE
اگر این گزینه را روی ۰ تنظیم کنید، اندازه اولیه برابر با مجموع اندازه‌های
تخصیص‌یافته برای نسل قدیم و نسل جوان تعیین می‌شود.
اندازه هیپ برای نسل جوان را می‌توان با استفاده از گزینه
\f[CR]\-XX:NewSize\f[R] تنظیم کرد.
توجه داشته باشید که گزینه \f[CR]\-Xms\f[R] هم کمینه و هم اندازه اولیه
هیپ را تعیین می‌کند.
اگر \f[CR]\-Xms\f[R] پس از \f[CR]\-XX:InitialHeapSize\f[R] در خط فرمان ظاهر شود،
اندازه اولیه هیپ روی مقدار مشخص‌شده با \f[CR]\-Xms\f[R] تنظیم می‌شود.
.RE.TP
\f[CR]\-XX:InitialRAMPercentage=\f[R]\f[I]percent\f[R]
مقدار اولیه حافظه‌ای را که JVM پیش از اعمال قواعد اکتشافی ارگونومی (ergonomics heuristics) برای هیپ جاوا استفاده خواهد کرد، بر حسب درصدی از حداکثر مقدار تعیین‌شده مطابق با گزینهٔ \f[CR]\-XX:MaxRAM\f[R] تنظیم می‌کند.
.RS
مثال زیر نحوه تنظیم درصد مقدار اولیه حافظه مورد استفاده برای هیپ جاوا را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:InitialRAMPercentage=5\f[R]
.RE
.RE
.TP
\f[CR]\-XX:InitialSurvivorRatio=\f[R]\f[I]ratio\f[R]
نسبت اولیه فضای survivor مورد استفاده توسط زباله‌روب توان عملیاتی (throughput garbage collector که با گزینهٔ \f[CR]\-XX:+UseParallelGC\f[R] فعال می‌شود) را تنظیم می‌کند.
اندازه‌بندی تطبیقی (Adaptive sizing) به‌طور پیش‌فرض در زباله‌روب توان عملیاتی با استفاده از گزینهٔ \f[CR]\-XX:+UseParallelGC\f[R] فعال است، و اندازه فضای survivor متناسب با رفتار برنامه، با شروع از مقدار اولیه، تغییر می‌یابد.
اگر اندازه‌بندی تطبیقی غیرفعال باشد (با استفاده از گزینهٔ \f[CR]\-XX:\-UseAdaptiveSizePolicy\f[R])، آنگاه باید از گزینهٔ \f[CR]\-XX:SurvivorRatio\f[R] برای تنظیم اندازه فضای survivor در کل مدت زمان اجرای برنامه استفاده شود.
.RS
فرمول زیر می‌تواند برای محاسبه اندازه اولیه فضای survivor (به اختصار S) بر اساس اندازه نسل جوان یا young generation (به اختصار Y) و نسبت اولیه فضای survivor (به اختصار R) استفاده شود:
.RS
.PP
\f[CR]S=Y/(R+2)\f[R]
.RE
عدد ۲ در معادله نشان‌دهنده دو فضای survivor است.
هرچه مقدار تعیین‌شده برای نسبت اولیه فضای survivor بزرگ‌تر باشد، اندازه اولیه فضای survivor کوچک‌تر خواهد بود.
به‌طور پیش‌فرض، نسبت اولیه فضای survivor روی ۸ تنظیم شده است.
اگر از مقدار پیش‌فرض برای اندازه فضای نسل جوان استفاده شود (۲ مگابایت)، اندازه اولیه فضای survivor برابر ۰٫۲ مگابایت خواهد بود.
مثال زیر نحوه تنظیم نسبت اولیه فضای survivor روی ۴ را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:InitialSurvivorRatio=4\f[R]
.RE
.RE
.TP
\f[CR]\-XX:InitiatingHeapOccupancyPercent=\f[R]\f[I]percent\f[R]
درصد اشغال نسل قدیم یا old generation (بین ۰ تا ۱۰۰) را برای شروع چرخه‌های اولیه نشانه‌گذاری همگام (concurrent marking) در زباله‌روب G1 تنظیم می‌کند.
.RS
به‌طور پیش‌فرض، این مقدار آغازگر روی ۴۵٪ تنظیم شده است.
مقدار ۰ به معنای چرخه‌های GC همگام و بی‌وقفه از همان ابتدا است تا زمانی که G1 این مقدار را به‌صورت تطبیقی تنظیم کند.
همچنین گزینه‌های \f[CR]\-XX:G1UseAdaptiveIHOP\f[R] و \f[CR]\-XX:G1AdaptiveIHOPNumInitialSamples\f[R] را ببینید.
مثال زیر نحوه تنظیم درصد اشغال آغازگر هیپ روی ۷۵٪ را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:InitiatingHeapOccupancyPercent=75\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxGCPauseMillis=\f[R]\f[I]time\f[R]
یک هدف برای حداکثر زمان توقف GC (بر حسب میلی‌ثانیه) تعیین می‌کند.
این یک هدف انعطاف‌پذیر (soft goal) است و JVM تمام تلاش خود را برای رسیدن به آن انجام خواهد داد.
تنها G1 و Parallel از هدف حداکثر زمان توقف GC پشتیبانی می‌کنند.
برای G1، مقدار پیش‌فرض هدف حداکثر زمان توقف ۲۰۰ میلی‌ثانیه است.
.RS
مثال زیر نحوه تنظیم حداکثر زمان هدف توقف به ۵۰۰ میلی‌ثانیه را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:MaxGCPauseMillis=500\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxHeapSize=\f[R]\f[I]size\f[R]
حداکثر اندازه (بر حسب بایت) مخزن تخصیص حافظه را تنظیم می‌کند.
این مقدار باید مضربی از ۱۰۲۴ و بزرگ‌تر از ۲ مگابایت باشد.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای نشان دادن کیلوبایت، \f[CR]m\f[R] یا \f[CR]M\f[R] را برای نشان دادن مگابایت، یا \f[CR]g\f[R] یا \f[CR]G\f[R] را برای نشان دادن گیگابایت اضافه کنید.
مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود.
برای استقرارهای سرور، گزینه‌های \f[CR]\-XX:InitialHeapSize\f[R] و \f[CR]\-XX:MaxHeapSize\f[R] اغلب روی مقداری یکسان تنظیم می‌شوند.
.RS
مثال‌های زیر نحوه تنظیم حداکثر اندازه مجاز حافظه تخصیص‌یافته روی ۸۰ مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:
.IP
.EX
\-XX:MaxHeapSize=83886080
\-XX:MaxHeapSize=81920k
\-XX:MaxHeapSize=80m
.EE
گزینهٔ \f[CR]\-XX:MaxHeapSize\f[R] معادل \f[CR]\-Xmx\f[R] است.
.RE
.TP
\f[CR]\-XX:MaxHeapFreeRatio=\f[R]\f[I]percent\f[R]
حداکثر درصد مجاز فضای آزاد هیپ (۰ تا ۱۰۰) پس از یک رخداد GC را تعیین می‌کند.
اگر فضای آزاد هیپ فراتر از این مقدار گسترش یابد، اندازه هیپ کوچک‌تر (shrink) می‌شود.
به‌طور پیش‌فرض، این مقدار روی ۷۰٪ تنظیم شده است.
.RS
با کاهش مقادیر پارامترهای \f[CR]MaxHeapFreeRatio\f[R] (مقدار پیش‌فرض ۷۰٪) و \f[CR]MinHeapFreeRatio\f[R] (مقدار پیش‌فرض ۴۰٪) از طریق گزینه‌های خط فرمان \f[CR]\-XX:MaxHeapFreeRatio\f[R] و \f[CR]\-XX:MinHeapFreeRatio\f[R]، اندازه هیپ جاوا را به حداقل برسانید.
کاهش \f[CR]MaxHeapFreeRatio\f[R] تا مقدار کم ۱۰٪ و \f[CR]MinHeapFreeRatio\f[R] تا ۵٪ با موفقیت اندازه هیپ را بدون افت عملکرد زیاد کاهش داده است؛ با این حال، نتایج ممکن است بسته به برنامه شما بسیار متفاوت باشد.
مقادیر مختلف را برای این پارامترها امتحان کنید تا جایی که تا حد امکان کاهش یابند و در عین حال کارایی قابل قبولی را حفظ کنند.
.RS
.PP
\f[CR]\-XX:MaxHeapFreeRatio=10 \-XX:MinHeapFreeRatio=5\f[R]
.RE
کاربرانی که سعی در کوچک نگه‌داشتن هیپ دارند، باید گزینهٔ \f[CR]\-XX:\-ShrinkHeapInSteps\f[R] را نیز اضافه کنند.
برای توضیحات مربوط به استفاده از این گزینه جهت کوچک نگه‌داشتن هیپ جاوا با کاهش ردپای پویا (dynamic footprint) برای برنامه‌های تعبیه‌شده (embedded)، به \f[B]Performance Tuning Examples\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-XX:MaxMetaspaceSize=\f[R]\f[I]size\f[R]
حداکثر میزان حافظه بومی (native memory) قابل تخصیص برای فراداده‌های کلاس (class metadata) را تنظیم می‌کند.
به‌طور پیش‌فرض، این اندازه محدود نیست.
میزان فراداده‌ها برای یک برنامه به خود برنامه، سایر برنامه‌های در حال اجرا و میزان حافظه در دسترس در سیستم بستگی دارد.
.RS
مثال زیر نحوه تنظیم حداکثر اندازه فراداده‌های کلاس روی ۲۵۶ مگابایت را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:MaxMetaspaceSize=256m\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxNewSize=\f[R]\f[I]size\f[R]
حداکثر اندازه (بر حسب بایت) هیپ برای نسل جوان (nursery) را تعیین می‌کند.
مقدار پیش‌فرض به‌صورت ارگونومیک (ergonomically) تنظیم می‌شود.
.TP
\f[CR]\-XX:MaxRAMPercentage=\f[R]\f[I]percent\f[R]
حداکثر میزان حافظه‌ای را که JVM می‌تواند پیش از اعمال قواعد اکتشافی ارگونومی برای هیپ جاوا استفاده کند، به صورت درصدی از حداکثر مقدار تعیین‌شده مطابق با گزینهٔ \f[CR]\-XX:MaxRAM\f[R] تنظیم می‌کند.
مقدار پیش‌فرض ۲۵ درصد است.
.RS
مشخص کردن این گزینه در صورتی که نتیجه ترکیبی این گزینه و سایر گزینه‌های اثرگذار بر حداکثر میزان حافظه از محدوده حافظه آدرس‌پذیر توسط compressed oops بزرگ‌تر باشد، استفاده خودکار از compressed oops را غیرفعال می‌کند.
برای اطلاعات بیشتر درباره compressed oops به \f[CR]\-XX:UseCompressedOops\f[R] مراجعه کنید.
مثال زیر نحوه تنظیم درصد حداکثر میزان حافظه مورد استفاده برای هیپ جاوا را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:MaxRAMPercentage=75\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MinRAMPercentage=\f[R]\f[I]percent\f[R]
حداکثر میزان حافظه‌ای را که JVM می‌تواند پیش از اعمال قواعد اکتشافی ارگونومی برای هیپ جاوا در هیپ‌های کوچک (small heaps) استفاده کند، به صورت درصدی از حداکثر مقدار تعیین‌شده بر اساس گزینهٔ \f[CR]\-XX:MaxRAM\f[R] تنظیم می‌کند.
یک هیپ کوچک، هیپی با اندازه تقریبی ۱۲۵ مگابایت است.
مقدار پیش‌فرض ۵۰ درصد است.
.RS
مثال زیر نحوه تنظیم درصد حداکثر میزان حافظه مورد استفاده برای هیپ جاوا در هیپ‌های کوچک را نشان می‌دهد:
.RS.PP
\f[CR]\-XX:MinRAMPercentage=75\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MaxTenuringThreshold=\f[R]\f[I]threshold\f[R]
حداکثر آستانه ارتقا (tenuring threshold) را برای استفاده در تعیین اندازه تطبیقی GC تنظیم می‌کند.
بزرگ‌ترین مقدار 15 است.
مقدار پیش‌فرض برای گردآورنده موازی (throughput) برابر با 15 است.
.RS
مثال زیر نحوه تنظیم حداکثر آستانه ارتقا روی 10 را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:MaxTenuringThreshold=10\f[R]
.RE
.RE
.TP
\f[CR]\-XX:MetaspaceSize=\f[R]\f[I]size\f[R]
اندازه فضای تخصیص‌یافته فراداده‌های کلاس را تنظیم می‌کند که فراتر رفتن از آن برای نخستین بار، باعث اجرای بازیافت حافظه (garbage collection) می‌شود.
این آستانه برای بازیافت حافظه، بسته به میزان فراداده‌های استفاده‌شده افزایش یا کاهش می‌یابد.
اندازه پیش‌فرض به بستر بستگی دارد.
.TP
\f[CR]\-XX:MinHeapFreeRatio=\f[R]\f[I]percent\f[R]
حداقل درصد مجاز فضای آزاد حافظه هیپ (0 تا 100) را پس از یک رخداد GC تعیین می‌کند.
اگر فضای آزاد هیپ کمتر از این مقدار شود، هیپ گسترش می‌یابد.
به‌طور پیش‌فرض، این مقدار روی 40% تنظیم شده است.
.RS
اندازه هیپ جاوا را با کاهش مقادیر پارامترهای
\f[CR]MaxHeapFreeRatio\f[R] (مقدار پیش‌فرض 70%) و
\f[CR]MinHeapFreeRatio\f[R] (مقدار پیش‌فرض 40%) با استفاده از گزینه‌های خط فرمان
\f[CR]\-XX:MaxHeapFreeRatio\f[R] و \f[CR]\-XX:MinHeapFreeRatio\f[R] به حداقل برسانید.
کاهش \f[CR]MaxHeapFreeRatio\f[R] تا 10% و
\f[CR]MinHeapFreeRatio\f[R] تا 5% با موفقیت اندازه هیپ را بدون افت کارایی چشمگیر کاهش داده است؛ با این حال، نتایج ممکن است بسته به برنامه شما بسیار متفاوت باشد.
مقادیر مختلفی را برای این پارامترها امتحان کنید تا جایی که تا حد امکان پایین بیایند و هم‌زمان کارایی قابل قبولی را حفظ کنند.
.RS
.PP
\f[CR]\-XX:MaxHeapFreeRatio=10 \-XX:MinHeapFreeRatio=5\f[R]
.RE
کاربرانی که می‌خواهند اندازه هیپ را کوچک نگه دارند باید گزینه
\f[CR]\-XX:\-ShrinkHeapInSteps\f[R] را نیز اضافه کنند.
برای شرح نحوه استفاده از این گزینه جهت کوچک نگه داشتن هیپ جاوا با کاهش ردپای پویای حافظه برای برنامه‌های تعبیه‌شده (embedded)، به بخش \f[B]Performance Tuning Examples\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-XX:MinHeapSize=\f[R]\f[I]size\f[R]
حداقل اندازه (به بایت) استخر تخصیص حافظه را تنظیم می‌کند.
این مقدار باید 0، یا مضربی از 1024 و بزرگ‌تر از 1 مگابایت باشد.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای مشخص کردن کیلوبایت،
\f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا
\f[CR]G\f[R] را برای گیگابایت الحاق کنید.
مقدار پیش‌فرض در زمان اجرا بر اساس پیکربندی سیستم انتخاب می‌شود.
.RS
مثال‌های زیر نحوه تنظیم حداقل اندازه حافظه تخصیص‌یافته به 6 مگابایت را با استفاده از واحدهای مختلف نشان می‌دهند:
.IP
.EX
\-XX:MinHeapSize=6291456
\-XX:MinHeapSize=6144k
\-XX:MinHeapSize=6m
.EE
اگر این گزینه را روی 0 تنظیم کنید، حداقل اندازه برابر با مقدار اندازه اولیه در نظر گرفته می‌شود.
.RE
.TP
\f[CR]\-XX:NewRatio=\f[R]\f[I]ratio\f[R]
نسبت بین اندازه نسل جوان (young) و قدیم (old) را تنظیم می‌کند.
به‌طور پیش‌فرض، این گزینه روی 2 تنظیم شده است.
مثال زیر نحوه تنظیم نسبت نسل جوان به قدیم را روی 1 نشان می‌دهد:
.RS
.RS
.PP
\f[CR]\-XX:NewRatio=1\f[R]
.RE
.RE
.TP
\f[CR]\-XX:NewSize=\f[R]\f[I]size\f[R]
اندازه اولیه (به بایت) هیپ را برای نسل جوان (nursery) تعیین می‌کند.
حرف \f[CR]k\f[R] یا \f[CR]K\f[R] را برای تعیین کیلوبایت،
\f[CR]m\f[R] یا \f[CR]M\f[R] را برای مگابایت، یا \f[CR]g\f[R] یا
\f[CR]G\f[R] را برای گیگابایت اضافه کنید.
.RS
ناحیه نسل جوان در هیپ برای اشیاء جدید استفاده می‌شود.
عملیات GC در این ناحیه بیشتر از سایر نواحی انجام می‌گیرد.
اگر اندازه نسل جوان بیش از حد کم باشد، تعداد زیادی minor GC انجام خواهد شد.
اگر این اندازه بیش از حد زیاد باشد، فقط full GC انجام می‌شود که تکمیل آن می‌تواند زمان زیادی ببرد.
توصیه می‌شود اندازه نسل جوان را بیش از 25% و کمتر از 50% از کل اندازه هیپ نگه دارید.
مثال‌های زیر نحوه تنظیم اندازه اولیه نسل جوان را به 256 مگابایت با واحدهای مختلف نشان می‌دهند:
.IP
.EX
\-XX:NewSize=256m
\-XX:NewSize=262144k
\-XX:NewSize=268435456
.EE
گزینه \f[CR]\-XX:NewSize\f[R] معادل با \f[CR]\-Xmn\f[R] است.
.RE
.TP
\f[CR]\-XX:ParallelGCThreads=\f[R]\f[I]threads\f[R]
تعداد رشته‌های کاری stop\-the\-world (STW) را تنظیم می‌کند.
مقدار پیش‌فرض به تعداد CPUهای در دسترس برای JVM و گردآورنده زباله انتخاب‌شده بستگی دارد.
.RS
به‌عنوان مثال، برای تنظیم تعداد رشته‌ها برای G1 GC به 2، گزینه زیر را مشخص کنید:
.RS
.PP
\f[CR]\-XX:ParallelGCThreads=2\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+PrintAdaptiveSizePolicy\f[R]
چاپ اطلاعات مربوط به تعیین اندازه تطبیقی نسل‌ها را فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است.
.TP
\f[CR]\-XX:SoftRefLRUPolicyMSPerMB=\f[R]\f[I]time\f[R]
مدت زمانی (به میلی‌ثانیه) را که یک شیء با دسترسی‌پذیری ضعیف (softly reachable) پس از آخرین ارجاع در هیپ فعال نگه داشته می‌شود، تعیین می‌کند.
مقدار پیش‌فرض یک ثانیه طول عمر به ازای هر مگابایت فضای آزاد در هیپ است.
گزینه \f[CR]\-XX:SoftRefLRUPolicyMSPerMB\f[R] مقادیر صحیحی را می‌پذیرد که نشان‌دهنده میلی‌ثانیه به ازای هر یک مگابایت از اندازه فعلی هیپ (برای Java HotSpot Client VM) یا حداکثر اندازه ممکن هیپ (برای Java HotSpot Server VM) هستند.
این تفاوت بدین معناست که Client VM تمایل دارد به جای گسترش هیپ، ارجاع‌های نرم (soft references) را پاک‌سازی کند، در حالی که Server VM تمایل دارد به جای پاک‌سازی ارجاع‌های نرم، هیپ را گسترش دهد.
در حالت دوم، مقدار گزینه \f[CR]\-Xmx\f[R] تأثیر چشمگیری بر سرعت بازیافت ارجاع‌های نرم دارد.
.RS
مثال زیر نحوه تنظیم مقدار را روی 2.5 ثانیه نشان می‌دهد:
\f[CR]\-XX:SoftRefLRUPolicyMSPerMB=2500\f[R]
.RE
.TP
\f[CR]\-XX:\-ShrinkHeapInSteps\f[R]
هیپ جاوا را به‌صورت تدریجی تا اندازه هدف که با گزینه \f[CR]\-XX:MaxHeapFreeRatio\f[R] مشخص شده، کاهش می‌دهد.
این گزینه به‌طور پیش‌فرض فعال است.
در صورت غیرفعال بودن، به جای نیاز به چندین چرخه بازیافت حافظه، اندازه هیپ جاوا بلافاصله به اندازه هدف کاهش می‌یابد.
اگر می‌خواهید اندازه هیپ جاوا را به حداقل برسانید، این گزینه را غیرفعال کنید.
در صورت غیرفعال بودن این گزینه، به احتمال زیاد با افت کارایی مواجه خواهید شد.
.RS
برای شرح نحوه استفاده از گزینه \f[CR]MaxHeapFreeRatio\f[R] جهت کوچک نگه داشتن هیپ جاوا با کاهش ردپای پویای حافظه برای برنامه‌های تعبیه‌شده، به \f[B]Performance Tuning Examples\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-XX:StringDeduplicationAgeThreshold=\f[R]\f[I]threshold\f[R]
اشیای \f[CR]String\f[R] را که با رسیدن به سن مشخص‌شده نامزد حذف داده‌های تکراری (deduplication) می‌شوند، تعیین می‌کند.
سن یک شیء، معیاری از تعداد دفعاتی است که از بازیافت حافظه جان سالم به در برده است.
گاهی از این فرایند با عنوان ارتقا (tenuring) یاد می‌شود.
.RS
.RS
.PP
\f[B]نکته:\f[R] اشیای \f[CR]String\f[R] که پیش از رسیدن به این سن به ناحیه قدیمی هیپ ارتقا می‌یابند، همیشه نامزد deduplication در نظر گرفته می‌شوند.
مقدار پیش‌فرض این گزینه \f[CR]3\f[R] است.
گزینه \f[CR]\-XX:+UseStringDeduplication\f[R] را ببینید.
.RE
.RE
.TP
\f[CR]\-XX:SurvivorRatio=\f[R]\f[I]ratio\f[R]
نسبت بین اندازه فضای eden و اندازه فضای survivor را تعیین می‌کند.
به‌طور پیش‌فرض، این گزینه روی 8 تنظیم شده است.
مثال زیر نحوه تنظیم نسبت فضای eden/survivor روی 4 را نشان می‌دهد:
.RS
.RS.PP
\f[CR]\-XX:SurvivorRatio=4\f[R]
.RE
.RE
.TP
\f[CR]\-XX:TargetSurvivorRatio=\f[R]\f[I]percent\f[R]
درصد مورد نظر از فضای بازمانده (survivor space) را که پس از زباله‌روبی
نسل جوان استفاده می‌شود (بین ۰ تا ۱۰۰)، تعیین می‌کند.
به‌طور پیش‌فرض، این گزینه روی 50% تنظیم شده است.
.RS
مثال زیر نحوه تنظیم نسبت هدف فضای بازمانده روی 30% را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:TargetSurvivorRatio=30\f[R]
.RE
.RE
.TP
\f[CR]\-XX:TLABSize=\f[R]\f[I]size\f[R]
اندازه اولیه (به بایت) یک بافر تخصیص محلی نخ (TLAB) را تعیین می‌کند.
برای نشان دادن کیلوبایت، حرف \f[CR]k\f[R] یا \f[CR]K\f[R]، برای
مگابایت، \f[CR]m\f[R] یا \f[CR]M\f[R]، یا برای گیگابایت، \f[CR]g\f[R]
یا \f[CR]G\f[R] را ضمیمه کنید.
اگر این گزینه روی 0 تنظیم شود، ماشین مجازی جاوا (JVM) اندازه اولیه را
به‌طور خودکار انتخاب می‌کند.
.RS
مثال زیر نحوه تنظیم اندازه اولیه TLAB روی 512 KB را نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:TLABSize=512k\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+UseAdaptiveSizePolicy\f[R]
استفاده از اندازه‌بندی تطبیقی نسل‌ها را فعال می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
برای غیرفعال کردن اندازه‌بندی تطبیقی نسل‌ها،
\f[CR]\-XX:\-UseAdaptiveSizePolicy\f[R] را مشخص کرده و اندازه استخر
تخصیص حافظه را به‌طور صریح تنظیم کنید.
گزینه \f[CR]\-XX:SurvivorRatio\f[R] را ببینید.
.TP
\f[CR]\-XX:+UseG1GC\f[R]
استفاده از زباله‌روب Garbage\-First (G1) را فعال می‌کند.
این یک زباله‌روب به سبک سرور است که برای ماشین‌های چندپردازنده‌ای با
مقدار زیادی RAM طراحی شده است.
این گزینه اهداف زمان مکث GC را با احتمال بالایی برآورده می‌کند، در حالی
که توان عملیاتی مناسبی را نیز حفظ می‌نماید.
زباله‌روب G1 برای برنامه‌هایی که نیاز به هیپ‌های بزرگ (اندازه‌های حدود
6 GB یا بزرگ‌تر) با نیازمندی‌های تأخیر محدود GC (زمان مکث پایدار و
قابل پیش‌بینی زیر 0.5 ثانیه) دارند، پیشنهاد می‌شود.
به‌طور پیش‌فرض، این گزینه فعال است و G1 به عنوان زباله‌روب پیش‌فرض
استفاده می‌شود.
.TP
\f[CR]\-XX:+UseGCOverheadLimit\f[R]
استفاده از سیاستی را فعال می‌کند که نسبت زمان صرف‌شده توسط JVM برای GC
را پیش از پرتاب استثنای \f[CR]OutOfMemoryError\f[R] محدود می‌سازد.
این گزینه به‌طور پیش‌فرض فعال است، و اگر بیش از 98% از کل زمان صرف
زباله‌روبی شود و کمتر از 2% از هیپ بازیابی گردد، GC موازی یک
\f[CR]OutOfMemoryError\f[R] پرتاب خواهد کرد.
هنگامی که هیپ کوچک است، می‌توان از این ویژگی برای جلوگیری از اجرای
طولانی‌مدت برنامه‌ها با پیشرفت کم یا بدون پیشرفت استفاده کرد.
برای غیرفعال کردن این گزینه، گزینه
\f[CR]\-XX:\-UseGCOverheadLimit\f[R] را مشخص کنید.
.TP
\f[CR]\-XX:+UseNUMA\f[R]
بهینه‌سازی کارایی برنامه را در ماشینی با معماری حافظه غیریکنواخت
(NUMA) از طریق افزایش استفاده برنامه از حافظه با تأخیر کمتر فعال
می‌کند.
مقدار پیش‌فرض این گزینه به زباله‌روب بستگی دارد.
.TP
\f[CR]\-XX:+UseParallelGC\f[R]
استفاده از زباله‌روب موازی پاک‌سازی (Parallel Scavenge، که با نام
زباله‌روب توان عملیاتی نیز شناخته می‌شود) را برای بهبود کارایی برنامه
شما از طریق بهره‌گیری از چندین پردازنده فعال می‌کند.
.RS
به‌طور پیش‌فرض، این گزینه غیرفعال است و از زباله‌روب پیش‌فرض استفاده
می‌شود.
.RE
.TP
\f[CR]\-XX:+UseSerialGC\f[R]
استفاده از زباله‌روب سریالی (Serial GC) را فعال می‌کند.
این گزینه عموماً بهترین انتخاب برای برنامه‌های کوچک و ساده‌ای است که به
هیچ قابلیت خاصی از زباله‌روبی نیاز ندارند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و از زباله‌روب پیش‌فرض استفاده
می‌شود.
.TP
\f[CR]\-XX:+UseStringDeduplication\f[R]
حذف موارد تکراری رشته‌ها (String deduplication) را فعال می‌کند.
به‌طور پیش‌فرض، این گزینه غیرفعال است.
برای استفاده از این گزینه، باید زباله‌روب Garbage\-First (G1) را فعال
کنید.
.RS
حذف موارد تکراری رشته‌ها با بهره‌گیری از این واقعیت که بسیاری از اشیاء
\f[CR]String\f[R] یکسان هستند، ردپای حافظه اشیاء \f[CR]String\f[R] را
روی هیپ جاوا کاهش می‌دهد.
به جای اینکه هر شیء \f[CR]String\f[R] به آرایه نویسه‌ای اختصاصی خود
اشاره کند، اشیاء یکسان \f[CR]String\f[R] می‌توانند به یک آرایه نویسه‌ای
مشترک اشاره کنند.
.RE
.TP
\f[CR]\-XX:+UseTLAB\f[R]
استفاده از بلوک‌های تخصیص محلی نخ (TLAB) را در فضای نسل جوان فعال
می‌کند.
این گزینه به‌طور پیش‌فرض فعال است.
برای غیرفعال کردن استفاده از TLABها، گزینه
\f[CR]\-XX:\-UseTLAB\f[R] را مشخص کنید.
.TP
\f[CR]\-XX:+UseZGC\f[R]
استفاده از زباله‌روب Z (موسوم به ZGC) را فعال می‌کند.
این یک زباله‌روب با تأخیر کم است که در ازای مقداری هزینه در توان
عملیاتی، حداکثر زمان‌های مکث چند میلی‌ثانیه‌ای را ارائه می‌دهد.
زمان‌های مکث مستقل از اندازه هیپ مورد استفاده هستند.
از اندازه‌های هیپ از 8MB تا 16TB پشتیبانی می‌کند.
.TP
\f[CR]\-XX:ZAllocationSpikeTolerance=\f[R]\f[I]factor\f[R]
میزان تحمل جهش تخصیص (allocation spike tolerance) را برای ZGC تعیین
می‌کند.
به‌طور پیش‌فرض، این گزینه روی 2.0 تنظیم شده است.
این ضریب، سطح جهش‌های تخصیص قابل انتظار را توصیف می‌کند.
برای مثال، استفاده از ضریب 3.0 به این معنی است که می‌توان انتظار داشت
نرخ تخصیص فعلی در هر زمان سه برابر شود.
.TP
\f[CR]\-XX:ZCollectionInterval=\f[R]\f[I]seconds\f[R]
حداکثر فاصله زمانی (به ثانیه) بین دو چرخه GC را هنگام استفاده از ZGC
تعیین می‌کند.
به‌طور پیش‌فرض، این گزینه روی 0 (غیرفعال) تنظیم شده است.
.TP
\f[CR]\-XX:ZFragmentationLimit=\f[R]\f[I]percent\f[R]
حداکثر قطعه‌قطعه شدن قابل قبول هیپ (به درصد) را برای ZGC تعیین می‌کند.
به‌طور پیش‌فرض، این گزینه روی 25 تنظیم شده است.
استفاده از مقدار کمتر باعث می‌شود هیپ با شدت بیشتری یکپارچه‌سازی
(compact) شود تا به بهای مصرف زمان بیشتر CPU، حافظه بیشتری بازیابی
گردد.
.TP
\f[CR]\-XX:+ZProactive\f[R]
چرخه‌های پیش‌دستانه GC را هنگام استفاده از ZGC فعال می‌کند.
به‌طور پیش‌فرض، این گزینه فعال است.
اگر انتظار برود که اجرای یک چرخه GC کمترین تأثیر را بر برنامه در حال
اجرا بگذارد، ZGC یک چرخه پیش‌دستانه GC را آغاز خواهد کرد.
این گزینه زمانی مفید است که برنامه اغلب بیکار باشد یا اشیاء بسیار کمی را
تخصیص دهد، اما همچنان بخواهید اندازه هیپ را پایین نگه دارید و اجازه دهید
پردازش مرجع‌ها حتی در زمان وجود فضای خالی زیاد در هیپ، انجام شود.
.TP
\f[CR]\-XX:+ZUncommit\f[R]
لغو تخصیص (uncommit کردن) حافظه استفاده‌نشده هیپ را هنگام استفاده از ZGC
فعال می‌کند.
به‌طور پیش‌فرض، این گزینه فعال است.
لغو تخصیص حافظه استفاده‌نشده هیپ، ردپای حافظه JVM را کاهش می‌دهد و آن
حافظه را برای استفاده سایر فرآیندها در دسترس قرار می‌دهد.
.TP
\f[CR]\-XX:ZUncommitDelay=\f[R]\f[I]seconds\f[R]
مدت زمانی (به ثانیه) را تعیین می‌کند که حافظه هیپ باید پیش از لغو
تخصیص، استفاده‌نشده باقی مانده باشد.
به‌طور پیش‌فرض، این گزینه روی 300 (۵ دقیقه) تنظیم شده است.
تخصیص (committing) و لغو تخصیص (uncommitting) حافظه، عملیات‌های نسبتاً
پرهزینه‌ای هستند.
استفاده از مقدار کمتر باعث می‌شود حافظه هیپ زودتر لغو تخصیص شود، که خطر
نیاز به تخصیص مجدد و زودهنگام آن را به همراه دارد.
.TP
\f[CR]\-XX:+UseShenandoahGC\f[R]
استفاده از زباله‌روب Shenandoah را فعال می‌کند.
این یک زباله‌روب هم‌روند با زمان مکث کم است.
زمان‌های مکث آن متناسب با اندازه هیپ نیستند.
زباله‌روب Shenandoah می‌تواند با اشاره‌گرهای فشرده کار کند.
برای اطلاعات بیشتر درباره اشاره‌گرهای فشرده،
\f[CR]\-XX:UseCompressedOops\f[R] را ببینید.
.TP
\f[CR]\-XX:ShenandoahGCMode=\f[R]\f[I]mode\f[R]
حالت GC را برای استفاده Shenandoah GC تعیین می‌کند.
به‌طور پیش‌فرض، این گزینه روی \f[CR]satb\f[R] تنظیم شده است.
این گزینه از جمله مشخص می‌کند چه موانعی (barriers) در حال استفاده هستند.
مقادیر ممکن برای حالت شامل موارد زیر است:
.RS
.TP
\f[CR]satb\f[R]
زباله‌روب هم‌روند «عکس فوری در آغاز» (Snapshot\-at\-the\-beginning) (سه
گذر: علامت‌گذاری\-انتقال\-به‌روزرسانی یا mark\-evac\-update).
این یک GC تک‌نسلی است.
.TP
\f[CR]generational\f[R]
این حالت نیز یک GC هم‌روند و «عکس فوری در آغاز» است، اما نسلی
(generational) می‌باشد.
لطفاً برای آگاهی از مزایا و خطرات آن، \f[B]JEP 404\f[R]
[https://openjdk.org/jeps/404] و \f[B]JEP 521\f[R]
[https://openjdk.org/jeps/521] را ببینید.
.RE.TP
\f[CR]\-XX:ShenandoahGCHeuristics=\f[R]\f[I]heuristics\f[R]
روش‌های اکتشافی (heuristics) را برای استفاده توسط Shenandoah GC تنظیم می‌کند.
به‌طور پیش‌فرض، این گزینه روی \f[CR]adaptive\f[R] تنظیم شده است.
این گزینه با انتخاب زمان آغاز GC، میزان پردازش در هر چرخه، و این‌که چه ویژگی‌های دیگری به‌طور خودکار فعال شوند، حالت GC انتخاب‌شده را بهینه‌سازی و تنظیم دقیق می‌کند.
هنگامی که \f[CR]\-XX:ShenandoahGCMode\f[R] برابر با \f[CR]generational\f[R] باشد، تنها گزینهٔ پشتیبانی‌شده همان حالت پیش‌فرض، یعنی \f[CR]adaptive\f[R] است.
.RS
روش‌های اکتشافی ممکن عبارتند از:
.TP
\f[CR]adaptive\f[R]
برای حفظ مقدار مشخص‌شده‌ای از حافظه heap آزاد در تمام اوقات، حتی در حین چرخهٔ GC.
.TP
\f[CR]static\f[R]
راه‌اندازی GC هنگامی که حافظه heap آزاد از یک آستانهٔ مشخص پایین‌تر برود.
.TP
\f[CR]compact\f[R]
اجرای مکررتر GC و با اهداف عمیق‌تر برای آزادسازی حافظه بیشتر.
.RE
.SH "گزینه‌های منسوخ‌شده جاوا (DEPRECATED JAVA OPTIONS)"
این گزینه‌های \f[CR]java\f[R] منسوخ شده‌اند و ممکن است در انتشار آیندهٔ JDK حذف شوند.
آن‌ها هنوز پذیرفته شده و اعمال می‌شوند، اما هنگام استفاده از آن‌ها یک هشدار صادر می‌شود.
.TP
\f[CR]\-Xloggc:\f[R]\f[I]filename\f[R]
فایلی را تنظیم می‌کند که اطلاعات تفصیلی رویدادهای GC باید برای ثبت وقایع (لاگ‌گیری) به آن هدایت شوند.
اگر هر دو گزینه با یک دستور java داده شوند، گزینهٔ \f[CR]\-Xloggc\f[R] بر \f[CR]\-verbose:gc\f[R] تقدم داشته و آن را بازنویسی می‌کند.
\f[CR]\-Xloggc:\f[R]\f[I]filename\f[R] با \f[CR]\-Xlog:gc:\f[R]\f[I]filename\f[R] جایگزین شده است.
بخش Enable Logging with the JVM Unified Logging Framework را ببینید.
.RS
مثال:
\f[CR]\-Xlog:gc:garbage\-collection.log\f[R]
.RE
.TP
\f[CR]\-XX:+FlightRecorder\f[R]
استفاده از Java Flight Recorder (JFR) را در طول زمان اجرای برنامه فعال می‌کند.
از نسخهٔ JDK 8u40 به بعد، استفاده از JFR دیگر نیازی به این گزینه ندارد.
.TP
\f[CR]\-XX:+ParallelRefProcEnabled\f[R]
پردازش موازی ارجاعات (reference processing) را فعال می‌کند.
به‌طور پیش‌فرض، زباله‌روب‌هایی که از چندین نخ استفاده می‌کنند، در صورتی که تعداد نخ‌های موازی مورد استفاده بیشتر از یک باشد، پردازش ارجاعات را به‌صورت موازی انجام می‌دهند.
این گزینه تنها زمانی در دسترس است که از زباله‌روب‌های throughput یا G1 استفاده شود (\f[CR]\-XX:+UseParallelGC\f[R] یا \f[CR]\-XX:+UseG1GC\f[R]).
سایر زباله‌روب‌هایی که از چندین نخ بهره می‌برند، پردازش ارجاعات را همواره به‌صورت موازی انجام می‌دهند.
.TP
\f[CR]\-XX:MaxRAM=\f[R]\f[I]size\f[R]
حداکثر مقدار حافظه‌ای را که JVM می‌تواند قبل از اعمال روش‌های اکتشافی ارگونومی برای Java heap استفاده کند، تنظیم می‌کند.
مقدار پیش‌فرض، مقدار حافظهٔ در دسترس فرایند JVM است.
.RS
حداکثر مقدار حافظهٔ در دسترس فرایند JVM، کمینهٔ حافظهٔ فیزیکی دستگاه و هرگونه محدودیت تعیین‌شده توسط محیط (مانند container) است.
مشخص کردن این گزینه در صورتی که نتیجهٔ ترکیبی این گزینه و سایر گزینه‌های مؤثر بر حداکثر مقدار حافظه، بزرگ‌تر از محدودهٔ حافظهٔ قابل آدرس‌دهی توسط compressed oops باشد، استفادهٔ خودکار از compressed oops را غیرفعال می‌کند.
برای اطلاعات بیشتر دربارهٔ compressed oops گزینهٔ \f[CR]\-XX:UseCompressedOops\f[R] را ببینید.
مثال زیر نحوهٔ تنظیم حداکثر مقدار حافظهٔ در دسترس را برای تعیین اندازهٔ Java heap روی ۲ گیگابایت نشان می‌دهد:
.RS
.PP
\f[CR]\-XX:MaxRAM=2G\f[R]
.RE
.RE
.TP
\f[CR]\-XX:+AggressiveHeap\f[R]
بهینه‌سازی Java heap را فعال می‌کند.
این گزینه پارامترهای گوناگونی را بر اساس پیکربندی رایانه (RAM و CPU) به‌گونه‌ای تنظیم می‌کند که برای کارهای طولانی‌مدت با تخصیص شدید حافظه بهینه باشند.
به‌طور پیش‌فرض، این گزینه غیرفعال است و اندازه‌های heap با تهاجم کمتری پیکربندی می‌شوند.
.TP
\f[CR]\-XX:+NeverActAsServerClassMachine\f[R]
حالت \(dqClient VM emulation\(dq را فعال می‌کند که تنها از کامپایلر C1 JIT، یک CodeCache با اندازهٔ ۳۲ مگابایت و Serial GC استفاده می‌کند.
حداکثر مقدار حافظه‌ای که JVM می‌تواند استفاده کند (کنترل‌شده توسط پرچم \f[CR]\-XX:MaxRAM=n\f[R]) به‌طور پیش‌فرض روی 1GB تنظیم می‌شود.
رشتهٔ \(dqemulated\-client\(dq به رشتهٔ نگارش JVM افزوده می‌شود.
.RS
این پرچم به‌طور پیش‌فرض تنها در Windows در حالت ۳۲ بیتی روی \f[CR]true\f[R] و در تمام موارد دیگر روی \f[CR]false\f[R] تنظیم شده است.
در صورت استفاده از هر یک از پرچم‌های زیر در خط فرمان، حالت \(dqClient VM emulation\(dq فعال نخواهد شد:
.IP
.EX
\-XX:{+|\-}TieredCompilation
\-XX:CompilationMode=mode
\-XX:TieredStopAtLevel=n
\-XX:{+|\-}EnableJVMCI
\-XX:{+|\-}UseJVMCICompiler
.EE
.RE.SH "گزینه‌های منسوخ جاوا (OBSOLETE JAVA OPTIONS)"
این گزینه‌های \f[CR]java\f[R] همچنان پذیرفته می‌شوند اما نادیده گرفته خواهند شد، و در صورت استفاده از آن‌ها یک هشدار صادر می‌شود.
.TP
\f[CR]\-\-illegal\-access=\f[R]\f[I]parameter\f[R]
مفهوم \f[I]کپسوله‌سازی قوی آسان‌گیرانه (relaxed strong encapsulation)\f[R] را آن‌گونه که در
\f[B]JEP 261\f[R]
[https://openjdk.org/jeps/261#Relaxed\-strong\-encapsulation]
تعریف شده است، کنترل می‌کرد.
این گزینه در JDK 16 توسط \f[B]JEP 396\f[R]
[https://openjdk.org/jeps/396] ناموصی (deprecated) اعلام شد و در JDK 17 توسط \f[B]JEP
403\f[R] [https://openjdk.org/jeps/403] کاملاً منسوخ گردید.
.SH "گزینه‌های حذف‌شده جاوا (REMOVED JAVA OPTIONS)"
هیچ گزینهٔ مستندشده‌ای از java در JDK 26 حذف نشده است.
.PP
برای مشاهدهٔ فهرست و توضیحات گزینه‌های حذف‌شده در نسخه‌های پیشین، بخش \f[I]Removed Java Options\f[R] را در منابع زیر ببینید:
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 25\f[R]
[https://docs.oracle.com/en/java/javase/25/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 24\f[R]
[https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 23\f[R]
[https://docs.oracle.com/en/java/javase/23/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 22\f[R]
[https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 21\f[R]
[https://docs.oracle.com/en/java/javase/21/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 20\f[R]
[https://docs.oracle.com/en/java/javase/20/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 19\f[R]
[https://docs.oracle.com/en/java/javase/19/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 18\f[R]
[https://docs.oracle.com/en/java/javase/18/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 17\f[R]
[https://docs.oracle.com/en/java/javase/17/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 16\f[R]
[https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 15\f[R]
[https://docs.oracle.com/en/java/javase/15/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 14\f[R]
[https://docs.oracle.com/en/java/javase/14/docs/specs/man/java.html]
.IP \(bu 2
\f[B]The \f[CB]java\f[B] Command, Release 13\f[R]
[https://docs.oracle.com/en/java/javase/13/docs/specs/man/java.html]
.IP \(bu 2
\f[B]Java Platform, Standard Edition Tools Reference, Release 12\f[R]
[https://docs.oracle.com/en/java/javase/12/tools/java.html#GUID\-3B1CE181\-CD30\-4178\-9602\-230B800D4FAE]
.IP \(bu 2
\f[B]Java Platform, Standard Edition Tools Reference, Release 11\f[R]
[https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID\-741FC470\-AA3E\-494A\-8D2B\-1B1FE4A990D1]
.IP \(bu 2
\f[B]Java Platform, Standard Edition Tools Reference, Release 10\f[R]
[https://docs.oracle.com/javase/10/tools/java.htm#JSWOR624]
.IP \(bu 2
\f[B]Java Platform, Standard Edition Tools Reference, Release 9\f[R]
[https://docs.oracle.com/javase/9/tools/java.htm#JSWOR624]
.IP \(bu 2
\f[B]Java Platform, Standard Edition Tools Reference, Release 8 for
Oracle JDK on Windows\f[R]
[https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BGBCIEFC]
.IP \(bu 2
\f[B]Java Platform, Standard Edition Tools Reference, Release 8 for
Oracle JDK on Solaris, Linux, and macOS\f[R]
[https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BGBCIEFC]
.SH "فایل‌های آرگومان خط فرمان جاوا (JAVA COMMAND\-LINE ARGUMENT FILES)"
شما می‌توانید با استفاده از فایل‌های آرگومان حاوی \f[CR]\(at\f[R] برای تعیین یک یا چند فایل متنی حاوی آرگومان‌ها (مانند گزینه‌ها و نام‌های کلاس) که به دستور \f[CR]java\f[R] ارسال می‌شوند، دستور \f[CR]java\f[R] را کوتاه یا ساده کنید.
این قابلیت به شما امکان می‌دهد دستورهای \f[CR]java\f[R] با هر طولی را در هر سیستم‌عاملی ایجاد کنید.
.PP
در خط فرمان، از پیشوند علامت اتساین (\f[CR]\(at\f[R]) برای مشخص کردن یک فایل آرگومان حاوی گزینه‌ها و نام‌های کلاس \f[CR]java\f[R] استفاده کنید.
هنگامی که دستور \f[CR]java\f[R] با فایلی مواجه می‌شود که با علامت اتساین (\f[CR]\(at\f[R]) آغاز شده است، محتویات آن فایل را درست به همان صورت که در خط فرمان تعیین می‌شدند، به یک فهرست آرگومان بسط می‌دهد.
.PP
راه‌انداز \f[CR]java\f[R] محتویات فایل آرگومان را تا زمانی که به گزینهٔ \f[CR]\-\-disable\-\(atfiles\f[R] برسد بسط می‌دهد.
شما می‌توانید از گزینهٔ \f[CR]\-\-disable\-\(atfiles\f[R] در هر جایی از خط فرمان، از جمله درون یک فایل آرگومان، برای متوقف کردن بسط فایل‌های آرگومان \f[CR]\(at\f[R] استفاده کنید.
.PP
موارد زیر نحو فایل‌های آرگومان \f[CR]java\f[R] را توصیف می‌کنند:
.IP \(bu 2
فایل آرگومان باید تنها شامل نویسه‌های ASCII یا نویسه‌هایی در کدگذاری پیش‌فرض سیستم باشد که با ASCII سازگارند، مانند UTF\-8.
.IP \(bu 2
اندازهٔ فایل آرگومان نباید از MAXINT (۲٬۱۴۷٬۴۸۳٬۶۴۷) بایت تجاوز کند.
.IP \(bu 2
راه‌انداز، نویسه‌های عام (wildcards) موجود در یک فایل آرگومان را بسط نمی‌دهد.
این بدان معناست که یک ستاره (\f[CR]*\f[R]) همان‌طور که هست به VM آغازین تحویل داده می‌شود.
برای مثال، \f[CR]*.java\f[R] به صورت \f[CR]*.java\f[R] باقی می‌ماند و بر خلاف آنچه در برخی پوسته‌های خط فرمان رخ می‌دهد، به \f[CR]Foo.java Bar.java ...\f[R] بسط داده نمی‌شود.
.IP \(bu 2
از نویسه‌های فاصله (white space) یا خط جدید برای جداسازی آرگومان‌های گنجانده‌شده در فایل استفاده کنید.
.IP \(bu 2
فاصله شامل یک نویسهٔ فاصله، \f[CR]\(rst\f[R]، \f[CR]\(rsn\f[R]، \f[CR]\(rsr\f[R] و \f[CR]\(rsf\f[R] است.
.RS 2
.PP
به عنوان مثال، می‌توان مسیری دارای فاصله داشت، مانند \f[CR]c:\(rsProgram Files\f[R]، که می‌تواند هم به صورت \f[CR]\(dqc:\(rs\(rsProgram Files\(dq\f[R] یا، برای پرهیز از کاراکتر گریز، به صورت \f[CR]c:\(rsProgram\(dq \(dqFiles\f[R] مشخص شود.
.RE
.IP \(bu 2
هر گزینه‌ای که حاوی فاصله باشد، مانند جزئی از یک مسیر، باید به طور کامل با نویسه‌های نقل‌قول (\(aq\(dq\(aq) احاطه شود.
.IP \(bu 2
یک رشتهٔ درون نقل‌قول می‌تواند حاوی نویسه‌های \f[CR]\(rsn\f[R]، \f[CR]\(rsr\f[R]، \f[CR]\(rst\f[R] و \f[CR]\(rsf\f[R] باشد.
این نویسه‌ها به کدهای ASCII متناظر خود تبدیل می‌شوند.
.IP \(bu 2
اگر نام یک فایل حاوی فاصله‌های درونی است، کل نام فایل را درون علامت‌های نقل‌قول دوگانه (double quotation) قرار دهید.
.IP \(bu 2
نام‌های فایل در یک فایل آرگومان نسبت به دایرکتوری جاری در نظر گرفته می‌شوند، نه نسبت به محل قرارگیری فایل آرگومان.
.IP \(bu 2
از علامت هش \f[CR]#\f[R] در فایل آرگومان برای مشخص کردن توضیحات (comments) استفاده کنید.
تمام نویسه‌های بعد از \f[CR]#\f[R] تا انتهای خط نادیده گرفته می‌شوند.
.IP \(bu 2
علامت‌های اتساین \f[CR]\(at\f[R] پیشوندی بیشتر برای گزینه‌های دارای پیشوند \f[CR]\(at\f[R] به عنوان کاراکتر گریز (escape) عمل می‌کنند (اولین \f[CR]\(at\f[R] حذف شده و باقی آرگومان‌ها به صورت لفظی به راه‌انداز تحویل داده می‌شوند).
.IP \(bu 2
خطوط را می‌توان با استفاده از نویسهٔ ادامه (\f[CR]\(rs\f[R]) در انتهای خط ادامه داد.
دو خط با حذف فاصله‌های ابتدایی به یکدیگر متصل می‌شوند.
برای جلوگیری از حذف فاصله‌های ابتدایی، می‌توان نویسهٔ ادامه (\f[CR]\(rs\f[R]) را در ستون اول قرار داد.
.IP \(bu 2
از آنجا که بک‌اسلش (\(rs) یک نویسهٔ گریز است، یک نویسهٔ بک‌اسلش باید با یک نویسهٔ بک‌اسلش دیگر گریز داده شود.
.IP \(bu 2
نقل‌قول جزئی مجاز است و با پایان فایل (end\-of\-file) بسته می‌شود.
.IP \(bu 2
یک نقل‌قول باز در انتهای خط متوقف می‌شود مگر اینکه \f[CR]\(rs\f[R] آخرین نویسه باشد، که در این صورت با حذف تمامی نویسه‌های فاصلهٔ ابتدایی به خط بعدی متصل می‌شود.
.IP \(bu 2
استفاده از علامت اتساین (\f[CR]\(at\f[R]) برای تفسیر بازگشتی فایل‌ها پشتیبانی نمی‌شود..SS مثال نقل‌قول‌های باز یا ناتمام در یک فایل آرگومان
در فایل آرگومان،
.IP
.EX
\-cp \(dqlib/
cool/
app/
jars
.EE
.PP
این مورد به این صورت تفسیر می‌شود:
.RS
.PP
\f[CR]\-cp lib/cool/app/jars\f[R]
.RE
.SS مثال گریز از نویسه بک‌اسلش با یک نویسه بک‌اسلش دیگر در یک فایل آرگومان
برای خروجی دادن موارد زیر:
.RS
.PP
\f[CR]\-cp c:\(rsProgram Files (x86)\(rsJava\(rsjre\(rslib\(rsext;c:\(rsProgram Files\(rsJava\(rsjre9\(rslib\(rsext\f[R]
.RE
.PP
نویسه بک‌اسلش باید در فایل آرگومان به این صورت مشخص شود:
.RS
.PP
\f[CR]\-cp \(dqc:\(rs\(rsProgram Files (x86)\(rs\(rsJava\(rs\(rsjre\(rs\(rslib\(rs\(rsext;c:\(rs\(rsProgram Files\(rs\(rsJava\(rs\(rsjre9\(rs\(rslib\(rs\(rsext\(dq\f[R]
.RE
.SS مثال استفاده از گریز EOL جهت الحاق خطوط در فایل آرگومان
در فایل آرگومان،
.IP
.EX
\-cp \(dq/lib/cool app/jars:\(rs
    /lib/another app/jars\(dq
.EE
.PP
این مورد به این صورت تفسیر می‌شود:
.RS
.PP
\f[CR]\-cp /lib/cool app/jars:/lib/another app/jars\f[R]
.RE
.SS مثال ادامه خط با فاصله‌های ابتدایی در یک فایل آرگومان
در فایل آرگومان،
.IP
.EX
\-cp \(dq/lib/cool\(rs
\(rsapp/jars\(dq
.EE
.PP
این مورد به این صورت تفسیر می‌شود:
.PP
\f[CR]\-cp /lib/cool app/jars\f[R]
.SS مثال‌های استفاده از یک فایل آرگومان منفرد
می‌توانید از یک فایل آرگومان تکی، مانند \f[CR]myargumentfile\f[R] در
مثال زیر، برای نگهداری تمام آرگومان‌های مورد نیاز \f[CR]java\f[R] استفاده کنید:
.RS
.PP
\f[CR]java \(atmyargumentfile\f[R]
.RE
.SS مثال‌های استفاده از فایل‌های آرگومان دارای مسیر
می‌توانید مسیرهای نسبی را در فایل‌های آرگومان بگنجانید؛ با این حال، این
مسیرها نسبت به دایرکتوری کاری فعلی سنجیده می‌شوند و نه نسبت به مسیر خودِ
فایل‌های آرگومان.
در مثال زیر، \f[CR]path1/options\f[R] و
\f[CR]path2/options\f[R] بیانگر فایل‌های آرگومان با مسیرهای مختلف هستند.
هر مسیر نسبی که درون آن‌ها باشد، نسبت به دایرکتوری کاری فعلی سنجیده
می‌شود و نه فایل‌های آرگومان:
.RS
.PP
\f[CR]java \(atpath1/options \(atpath2/classes\f[R]
.RE
.SH "تحلیل وضعیت هیپ کد (CODE HEAP STATE ANALYTICS)"
.SS نمای کلی
مواقعی وجود دارد که داشتن دید و شناخت نسبت به وضعیت فعلی
هیپ کد JVM می‌تواند برای پاسخ به سوالاتی از قبیل موارد زیر مفید باشد:
.IP \(bu 2
چرا JIT خاموش شد و سپس بارها و بارها دوباره روشن شد؟
.IP \(bu 2
تمام فضای هیپ کد کجا مصرف شده است؟
.IP \(bu 2
چرا method sweeper به‌طور موثر عمل نمی‌کند؟
.PP
جهت ارائه این بینش، قابلیت تحلیل وضعیت هیپ کد پیاده‌سازی شده است
که امکان تحلیل در لحظه (on\-the\-fly) هیپ کد را فراهم می‌کند.
فرآیند تحلیل به دو بخش تقسیم می‌شود.
بخش اول کل هیپ کد را بررسی کرده و تمام اطلاعاتی را که
مفید یا مهم تلقی می‌شوند جمع‌آوری و تجمیع می‌کند.
بخش دوم شامل چندین مرحله مستقل است که اطلاعات جمع‌آوری‌شده را
با تأکید بر جنبه‌های مختلف داده‌ها چاپ می‌کند.
جمع‌آوری داده‌ها و چاپ آن‌ها بر اساس درخواست (\(dqon request\(dq) انجام می‌شود..SS "نحو (Syntax)"
درخواست‌ها برای تحلیل بلادرنگ و آنی (real\-time, on\-the\-fly) را می‌توان با دستور زیر صادر کرد:
.RS
.PP
\f[CR]jcmd\f[R] \f[I]pid\f[R] \f[CR]Compiler.CodeHeap_Analytics\f[R]
[\f[I]function\f[R]] [\f[I]granularity\f[R]]
.RE
.PP
اگر صرفاً علاقه‌مندید بدانید پس از اجرای یک بار کاری نمونه (workload)، وضعیت code heap چگونه است، می‌توانید از این گزینه خط فرمان استفاده کنید:
.RS
.PP
\f[CR]\-Xlog:codecache=Trace\f[R]
.RE
.PP
برای مشاهده وضعیت code heap هنگام بروز شرایط \(dqCodeCache full\(dq، ماشین مجازی (VM) را با این گزینه خط فرمان راه‌اندازی کنید:
.RS
.PP
\f[CR]\-Xlog:codecache=Debug\f[R]
.RE
.PP
برای شرح مفصل قابلیت تحلیل وضعیت code heap، توابع پشتیبانی‌شده و گزینه‌های میزان جزئیات (granularity)، به \f[B]CodeHeap State Analytics (OpenJDK)\f[R]
[https://bugs.openjdk.org/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf]
مراجعه کنید.
.SH "فعال‌سازی ثبت وقایع با چارچوب یکپارچه وقایع JVM (ENABLE LOGGING WITH THE JVM UNIFIED LOGGING FRAMEWORK)"
از گزینه \f[CR]\-Xlog\f[R] برای پیکربندی یا فعال‌سازی ثبت وقایع با چارچوب یکپارچه ثبت وقایع ماشین مجازی جاوا (JVM) استفاده می‌شود.
.SS "خلاصه دستور (SYNOPSIS)"
.RS
.PP
\f[CR]\-Xlog\f[R][\f[CR]:\f[R][\f[I]what\f[R]][\f[CR]:\f[R][\f[I]output\f[R]][\f[CR]:\f[R][\f[I]decorators\f[R]][\f[CR]:\f[R]\f[I]output\-options\f[R][\f[CR],\f[R]...]]]]]
.PP
\f[CR]\-Xlog:\f[R]\f[I]directive\f[R]
.RE
.TP
\f[I]what\f[R]
ترکیبی از برچسب‌ها (tags) و سطوح (levels) را در قالب
\f[I]tag1\f[R][\f[CR]+\f[R]\f[I]tag2\f[R]...][\f[CR]*\f[R]][\f[CR]=\f[R]\f[I]level\f[R]][\f[CR],\f[R]...]
مشخص می‌کند.
مگر در حالتی که نویسه عمومی (\f[CR]*\f[R]) مشخص شده باشد، تنها پیام‌های ثبتی تطبیق داده می‌شوند که دقیقاً دارای برچسب‌های مشخص‌شده باشند.
به \f[B]\-Xlog Tags and Levels\f[R] مراجعه کنید.
.TP
\f[I]output\f[R]
نوع خروجی را تعیین می‌کند.
در صورت مشخص نکردن نوع \f[I]output\f[R]، مقدار پیش‌فرض \f[CR]stdout\f[R] خواهد بود.
به \f[B]\-Xlog Output\f[R] مراجعه کنید.
.TP
\f[I]decorators\f[R]
خروجی را برای استفاده از یک مجموعه سفارشی از تزیین‌کننده‌ها (decorators) پیکربندی می‌کند.
در صورت مشخص نکردن \f[I]decorators\f[R]، مقادیر پیش‌فرض \f[CR]uptime\f[R]،
\f[CR]level\f[R] و \f[CR]tags\f[R] خواهند بود.
به \f[B]Decorations\f[R] مراجعه کنید.
.TP
\f[I]output\-options\f[R]
گزینه‌های خروجی ثبت وقایع \f[CR]\-Xlog\f[R] را تعیین می‌کند.
.TP
\f[I]directive\f[R]
یک گزینه سراسری یا زیردستور: help، disable، async
.SS "توضیحات (DESCRIPTION)"
چارچوب ثبت وقایع یکپارچه ماشین مجازی جاوا (JVM)، یک سامانه مشترک ثبت وقایع را برای تمام مؤلفه‌های JVM فراهم می‌کند.
ثبت وقایع GC برای JVM تغییر یافته است تا از چارچوب جدید ثبت وقایع استفاده کند.
نگاشت پرچم‌های قدیمی GC به پیکربندی متناظر جدید Xlog در \f[B]Convert GC Logging Flags to Xlog\f[R] شرح داده شده است.
علاوه بر این، ثبت وقایع زمان اجرا (runtime) نیز برای استفاده از چارچوب یکپارچه ثبت وقایع JVM تغییر یافته است.
نگاشت پرچم‌های قدیمی ثبت وقایع زمان اجرا به پیکربندی متناظر جدید Xlog در \f[B]Convert Runtime Logging Flags to Xlog\f[R] شرح داده شده است.
.PP
موارد زیر یک مرجع سریع برای دستور \f[CR]\-Xlog\f[R] و نحو گزینه‌ها ارائه می‌دهد:
.TP
\f[CR]\-Xlog\f[R]
ثبت وقایع JVM را در سطح \f[CR]info\f[R] فعال می‌کند.
.TP
\f[CR]\-Xlog:help\f[R]
نحو کاربرد \f[CR]\-Xlog\f[R] و برچسب‌ها، سطوح و decorators دردسترس را به همراه نمونه خطوط فرمان و توضیحات چاپ می‌کند.
.TP
\f[CR]\-Xlog:disable\f[R]
تمام ثبت وقایع را خاموش می‌کند و تمام پیکربندی‌های چارچوب ثبت وقایع از جمله پیکربندی پیش‌فرض هشدارها و خطاها را پاک می‌کند.
.TP
\f[CR]\-Xlog\f[R][\f[CR]:\f[R]\f[I]option\f[R]]
چندین آرگومان را به ترتیبی که در خط فرمان ظاهر می‌شوند اعمال می‌کند.
چندین آرگومان \f[CR]\-Xlog\f[R] برای یک خروجی یکسان، بر اساس ترتیب داده‌شده یکدیگر را بازنویسی (override) می‌کنند.
.RS
مؤلفه \f[I]option\f[R] به صورت زیر تنظیم می‌شود:
.RS
.PP
[\f[I]tag\-selection\f[R]][\f[CR]:\f[R][\f[I]output\f[R]][\f[CR]:\f[R][\f[I]decorators\f[R]][\f[CR]:\f[R]\f[I]output\-options\f[R]]]]
.RE
حذف کردن \f[I]tag\-selection\f[R] به‌طور پیش‌فرض مجموعه برچسب \f[CR]all\f[R] و سطح \f[CR]info\f[R] را تعیین می‌کند.
.RS
.PP
\f[I]tag\f[R][\f[CR]+\f[R]...]
\f[CR]all\f[R]
.RE
برچسب \f[CR]all\f[R] یک فرابرچسب (meta tag) متشکل از تمامی مجموعه‌برچسب‌های دردسترس است.
ستاره (\f[CR]*\f[R]) در تعریف مجموعه‌برچسب، بیانگر تطبیق نویسه عمومی (wildcard) است.
تطبیق با نویسه عمومی تمام مجموعه‌برچسب‌هایی را انتخاب می‌کند که \f[I]دست‌کم\f[R] شامل برچسب‌های مشخص‌شده باشند.
بدون نویسه عمومی، تنها تطابق‌های دقیق از مجموعه‌برچسب‌های مشخص‌شده انتخاب می‌شوند.
مؤلفه \f[I]output\-options\f[R] عبارت است از:
.RS
.PP
\f[CR]filecount=\f[R]\f[I]file\-count\f[R] \f[CR]filesize=\f[R]\f[I]file
size with optional K, M or G suffix\f[R]
\f[CR]foldmultilines=\f[R]\f[I]<true|false>\f[R]
.RE
هنگامی که \f[CR]foldmultilines\f[R] برابر با true باشد، رویداد ثبت وقایعی که از چندین خط تشکیل شده باشد، با جایگزین کردن نویسه‌های خط جدید با توالی \f[CR]\(aq\(rs\(aq\f[R] و \f[CR]\(aqn\(aq\f[R] در خروجی، در قالب یک خط تکی جمع خواهد شد.
نویسه‌های تک بک‌اسلش موجود نیز با توالی دو بک‌اسلش جایگزین می‌شوند تا این تبدیل قابل بازگشت باشد.
استفاده از این گزینه با کدگذاری‌های نویسه UTF\-8 ایمن است، اما سایر کدگذاری‌ها ممکن است به درستی کار نکنند.
برای نمونه، ممکن است توالی‌های چندبایتی در Shift JIS و BIG5 را به‌صورت نادرست تبدیل کند.
.RE.SS پیکربندی پیش‌فرض
هنگامی که تنها گزینهٔ \f[CR]\-Xlog\f[R] و هیچ چیز دیگری در خط فرمان
مشخص نشده باشد، از پیکربندی پیش‌فرض استفاده می‌شود.
پیکربندی پیش‌فرض، بدون توجه به اینکه پیام با چه برچسب‌هایی مرتبط است،
تمامی پیام‌های دارای سطحی منطبق با warning یا error را ثبت می‌کند.
پیکربندی پیش‌فرض معادل وارد کردن دستور زیر در خط فرمان است:
.RS
.PP
\f[CR]\-Xlog:all=warning:stdout:uptime,level,tags\f[R]
.RE
.SS کنترل ثبت وقایع در زمان اجرا
ثبت وقایع را می‌توان در زمان اجرا از طریق دستورهای تشخیصی (با استفاده از
ابزار \f[B]jcmd\f[R]) نیز کنترل کرد.
هر آنچه را که می‌توان در خط فرمان مشخص کرد، به‌صورت پویا با دستور
\f[CR]VM.log\f[R] نیز قابل تعیین است.
از آنجا که دستورهای تشخیصی به‌طور خودکار در قالب MBeanها ارائه می‌شوند،
می‌توانید از JMX برای تغییر پیکربندی ثبت وقایع در زمان اجرا استفاده کنید.
.SS برچسب‌ها و سطوح \-Xlog
هر پیام ثبت وقایع، یک سطح و یک مجموعه برچسب مرتبط با خود دارد.
سطح پیام بیانگر میزان جزئیات آن است، و مجموعه برچسب مشخص می‌کند که
پیام شامل چه مواردی است یا با کدام مؤلفهٔ JVM ارتباط دارد (مانند
\f[CR]gc\f[R]، \f[CR]jit\f[R] یا \f[CR]os\f[R]).
نگاشت پرچم‌های GC به پیکربندی Xlog در \f[B]Convert GC Logging Flags to Xlog\f[R]
شرح داده شده است.
نگاشت پرچم‌های قدیمی ثبت وقایع زمان اجرا به پیکربندی متناظر Xlog در
\f[B]Convert Runtime Logging Flags to Xlog\f[R] شرح داده شده است.
.PP
\f[B]سطوح ثبت وقایع موجود:\f[R]
.IP \(bu 2
\f[CR]off\f[R]
.IP \(bu 2
\f[CR]trace\f[R]
.IP \(bu 2
\f[CR]debug\f[R]
.IP \(bu 2
\f[CR]info\f[R]
.IP \(bu 2
\f[CR]warning\f[R]
.IP \(bu 2
\f[CR]error\f[R]
.PP
\f[B]برچسب‌های ثبت وقایع موجود:\f[R]
.PP
به معنای واقعی کلمه ده‌ها برچسب ثبت وقایع وجود دارد که ترکیب‌های مناسب
آن‌ها گستره‌ای از خروجی‌های ثبت وقایع را فعال خواهد کرد.
مجموعهٔ کامل برچسب‌های ثبت وقایع موجود را می‌توان با استفاده از
\f[CR]\-Xlog:help\f[R] مشاهده کرد.
مشخص کردن \f[CR]all\f[R] به جای یک ترکیب برچسب، با تمامی ترکیب‌های
برچسب‌ها مطابقت خواهد داشت.
.SS خروجی \-Xlog
گزینهٔ \f[CR]\-Xlog\f[R] از انواع خروجی‌های زیر پشتیبانی می‌کند:
.IP \(bu 2
\f[CR]stdout\f[R] \-\-\- خروجی را به stdout می‌فرستد
.IP \(bu 2
\f[CR]stderr\f[R] \-\-\- خروجی را به stderr می‌فرستد
.IP \(bu 2
\f[CR]file=\f[R]\f[I]filename\f[R] \-\-\- خروجی را به فایل(های) متنی می‌فرستد.
.PP
هنگام استفاده از \f[CR]file=\f[R]\f[I]filename\f[R]، مشخص کردن
\f[CR]%p\f[R]، \f[CR]%t\f[R] و/یا \f[CR]%hn\f[R] در نام فایل
به‌ترتیب به PID، برچسب زمانی راه‌اندازی و نام میزبان JVM بسط می‌یابد.
همچنین می‌توانید فایل‌های متنی را برای مدیریت چرخش فایل بر اساس اندازهٔ
فایل و تعداد فایل‌های نگه‌داری‌شده در چرخش پیکربندی کنید.
برای نمونه، جهت چرخش فایل وقایع در هر 10 مگابایت و نگه‌داشتن 5 فایل در
چرخش، گزینه‌های \f[CR]filesize=10M, filecount=5\f[R] را مشخص کنید.
اندازهٔ هدف فایل‌ها تضمین نمی‌شود که دقیق باشد، بلکه تنها یک مقدار تقریبی است.
فایل‌ها به‌طور پیش‌فرض با حداکثر 5 فایل چرخشی با اندازهٔ هدف 20 مگابایت
چرخانده می‌شوند، مگر آن‌که خلاف آن پیکربندی شده باشد.
مشخص کردن \f[CR]filecount=0\f[R] به این معنی است که فایل وقایع نباید
چرخانده شود.
در این حالت، احتمال رونویسی شدن فایل وقایع از پیش موجود وجود دارد.
.SS حالت خروجی \-Xlog
به‌طور پیش‌فرض پیام‌های وقایع به‌صورت همگام خروجی داده می‌شوند \- یعنی هر
پیام به محض فراخوانی ثبت وقایع، در خروجی تعیین‌شده نوشته می‌شود.
در عوض می‌توانید با مشخص کردن عبارت زیر از حالت ثبت وقایع ناهمگام استفاده کنید:
.TP
\f[CR]\-Xlog:async[:[stall|drop]]\f[R]
.IP
.EX
ثبت تمامی وقایع به‌صورت ناهمگام.
.EE
.PP
در حالت ثبت وقایع ناهمگام، محل‌های ثبت وقایع تمامی پیام‌ها را در یک
بافر میانی صف‌بندی می‌کنند و یک ریسهٔ مستقل مسئول تخلیهٔ آن‌ها در
خروجی‌های متناظر است.
بافر میانی دارای اندازهٔ محدود است.
در صورت پر شدن بافر، پیامی که در حال صف‌بندی است یا دور انداخته می‌شود
(\f[CR]async:drop\f[R])، یا ریسه‌های ثبت وقایع تا زمانی که ریسهٔ تخلیه به
آن‌ها برسد متوقف می‌شوند (\f[CR]async:stall\f[R]).
اگر حالت خاصی انتخاب نشود، به‌طور پیش‌فرض \f[CR]async:drop\f[R] انتخاب
می‌شود.
در حالت \f[CR]async:drop\f[R] تضمین می‌شود که عملیات نوشتن مدخل‌های وقایع
غیرمسدودکننده (non\-blocking) باشد.
.PP
گزینهٔ \f[CR]\-XX:AsyncLogBufferSize=N\f[R] سهم حافظه بر حسب بایت را
برای بافر میانی مشخص می‌کند.
مقدار پیش‌فرض باید به اندازهٔ کافی بزرگ باشد تا پاسخگوی بیشتر موارد باشد.
کاربران در صورت نیاز می‌توانند مقداری سفارشی تعیین کنند تا بین بار اضافی
حافظه و دقت ثبت وقایع مصالحه برقرار کنند..SS تزیینات (Decorations)
پیام‌های لاگ با اطلاعاتی درباره پیام تزیین می‌شوند.
می‌توانید هر خروجی را برای استفاده از مجموعه‌ای سفارشی از تزیین‌کننده‌ها پیکربندی کنید.
ترتیب خروجی همیشه همان ترتیبی است که در جدول فهرست شده است.
می‌توانید تزییناتی را که قرار است استفاده شوند در زمان اجرا پیکربندی کنید.
تزیینات به ابتدای پیام لاگ اضافه می‌شوند.
برای مثال:
.IP
.EX
[6.567s][info][gc,old] Old collection complete
.EE
.PP
نادیده‌گرفتن \f[CR]decorators\f[R] به‌طور پیش‌فرض از \f[CR]uptime\f[R]،
\f[CR]level\f[R] و \f[CR]tags\f[R] استفاده می‌کند.
تزیین‌کننده \f[CR]none\f[R] خاص است و برای غیرفعال کردن تمام
تزیینات به کار می‌رود.
.PP
تزیین‌کننده‌های \f[CR]time\f[R] (\f[CR]t\f[R])، \f[CR]utctime\f[R] (\f[CR]utc\f[R])،
\f[CR]uptime\f[R] (\f[CR]u\f[R])، \f[CR]timemillis\f[R] (\f[CR]tm\f[R])،
\f[CR]uptimemillis\f[R] (\f[CR]um\f[R])، \f[CR]timenanos\f[R]
(\f[CR]tn\f[R])، \f[CR]uptimenanos\f[R] (\f[CR]un\f[R])،
\f[CR]hostname\f[R] (\f[CR]hn\f[R])، \f[CR]pid\f[R] (\f[CR]p\f[R])،
\f[CR]tid\f[R] (\f[CR]ti\f[R])، \f[CR]level\f[R] (\f[CR]l\f[R]) و
\f[CR]tags\f[R] (\f[CR]tg\f[R]) را می‌توان برای عدم استفاده از تزیین،
روی \f[CR]none\f[R] نیز تنظیم کرد.
.PP
تزیینات پیام‌های لاگ
.TS
tab(@);
lw(14.9n) lw(55.1n).
T{
تزیینات
T}@T{
توضیحات
T}
_
T{
\f[CR]time\f[R] یا \f[CR]t\f[R]
T}@T{
زمان و تاریخ جاری در قالب ISO\-8601.
T}
T{
\f[CR]utctime\f[R] یا \f[CR]utc\f[R]
T}@T{
ساعت هماهنگ جهانی (Universal Time Coordinated یا Coordinated Universal Time).
T}
T{
\f[CR]uptime\f[R] یا \f[CR]u\f[R]
T}@T{
زمان سپری‌شده از شروع JVM به ثانیه و میلی‌ثانیه.
برای مثال، 6.567s.
T}
T{
\f[CR]timemillis\f[R] یا \f[CR]tm\f[R]
T}@T{
همان مقدار تولیدشده توسط \f[CR]System.currentTimeMillis()\f[R].
T}
T{
\f[CR]uptimemillis\f[R] یا \f[CR]um\f[R]
T}@T{
میلی‌ثانیه‌های سپری‌شده از زمان شروع JVM.
T}
T{
\f[CR]timenanos\f[R] یا \f[CR]tn\f[R]
T}@T{
همان مقدار تولیدشده توسط \f[CR]System.nanoTime()\f[R].
T}
T{
\f[CR]uptimenanos\f[R] یا \f[CR]un\f[R]
T}@T{
نانوثانیه‌های سپری‌شده از زمان شروع JVM.
T}
T{
\f[CR]hostname\f[R] یا \f[CR]hn\f[R]
T}@T{
نام میزبان (hostname).
T}
T{
\f[CR]pid\f[R] یا \f[CR]p\f[R]
T}@T{
شناسه فرایند (PID).
T}
T{
\f[CR]tid\f[R] یا \f[CR]ti\f[R]
T}@T{
شناسه نخ (Thread identifier).
T}
T{
\f[CR]level\f[R] یا \f[CR]l\f[R]
T}@T{
سطح مرتبط با پیام لاگ.
T}
T{
\f[CR]tags\f[R] یا \f[CR]tg\f[R]
T}@T{
مجموعه برچسب‌های مرتبط با پیام لاگ.
T}
.TE.SS تبدیل پرچم‌های لاگ‌گیری GC به Xlog
.PP
نگاشت پرچم‌های قدیمی لاگ‌گیری GC به پیکربندی Xlog
.TS
tab(@);
lw(22.4n) lw(16.5n) lw(31.2n).
T{
پرچم قدیمی زباله‌روبی (GC)
T}@T{
پیکربندی Xlog
T}@T{
توضیحات
T}
_
T{
\f[CR]G1PrintHeapRegions\f[R]
T}@T{
\f[CR]\-Xlog:gc+region=trace\f[R]
T}@T{
کاربرد ندارد
T}
T{
\f[CR]GCLogFileSize\f[R]
T}@T{
هیچ پیکربندی‌ای در دسترس نیست
T}@T{
چرخش لاگ توسط چارچوب مدیریت می‌شود.
T}
T{
\f[CR]NumberOfGCLogFiles\f[R]
T}@T{
کاربرد ندارد
T}@T{
چرخش لاگ توسط چارچوب مدیریت می‌شود.
T}
T{
\f[CR]PrintAdaptiveSizePolicy\f[R]
T}@T{
\f[CR]\-Xlog:gc+ergo*=\f[R]\f[I]level\f[R]
T}@T{
از یک \f[I]level\f[R] با مقدار \f[CR]debug\f[R] برای بیش‌تر اطلاعات،
یا یک \f[I]level\f[R] با مقدار \f[CR]trace\f[R] برای همهٔ آنچه که توسط
\f[CR]PrintAdaptiveSizePolicy\f[R] لاگ می‌شد، استفاده کنید.
T}
T{
\f[CR]PrintGC\f[R]
T}@T{
\f[CR]\-Xlog:gc\f[R]
T}@T{
کاربرد ندارد
T}
T{
\f[CR]PrintGCApplicationConcurrentTime\f[R]
T}@T{
\f[CR]\-Xlog:safepoint\f[R]
T}@T{
توجه داشته باشید که \f[CR]PrintGCApplicationConcurrentTime\f[R] و
\f[CR]PrintGCApplicationStoppedTime\f[R] با یک برچسب مشترک لاگ می‌شوند و
در سیستم لاگ‌گیری جدید تفکیک نشده‌اند.
T}
T{
\f[CR]PrintGCApplicationStoppedTime\f[R]
T}@T{
\f[CR]\-Xlog:safepoint\f[R]
T}@T{
توجه داشته باشید که \f[CR]PrintGCApplicationConcurrentTime\f[R] و
\f[CR]PrintGCApplicationStoppedTime\f[R] با یک برچسب مشترک لاگ می‌شوند و
در سامانه جدید لاگ‌گیری تفکیک نشده‌اند.
T}
T{
\f[CR]PrintGCCause\f[R]
T}@T{
کاربرد ندارد
T}@T{
علت GC اکنون همیشه در لاگ ثبت می‌شود.
T}
T{
\f[CR]PrintGCDateStamps\f[R]
T}@T{
کاربرد ندارد
T}@T{
برچسب‌های تاریخ توسط چارچوب ثبت می‌شوند.
T}
T{
\f[CR]PrintGCDetails\f[R]
T}@T{
\f[CR]\-Xlog:gc*\f[R]
T}@T{
کاربرد ندارد
T}
T{
\f[CR]PrintGCID\f[R]
T}@T{
کاربرد ندارد
T}@T{
شناسه GC اکنون همیشه لاگ می‌شود.
T}
T{
\f[CR]PrintGCTaskTimeStamps\f[R]
T}@T{
\f[CR]\-Xlog:gc+task*=debug\f[R]
T}@T{
کاربرد ندارد
T}
T{
\f[CR]PrintGCTimeStamps\f[R]
T}@T{
کاربرد ندارد
T}@T{
برچسب‌های زمانی توسط چارچوب ثبت می‌شوند.
T}
T{
\f[CR]PrintHeapAtGC\f[R]
T}@T{
\f[CR]\-Xlog:gc+heap=trace\f[R]
T}@T{
کاربرد ندارد
T}
T{
\f[CR]PrintReferenceGC\f[R]
T}@T{
\f[CR]\-Xlog:gc+ref*=debug\f[R]
T}@T{
توجه داشته باشید که در لاگ‌گیری قدیمی، \f[CR]PrintReferenceGC\f[R] تنها در
صورتی تأثیر داشت که \f[CR]PrintGCDetails\f[R] نیز فعال شده باشد.
T}
T{
\f[CR]PrintStringDeduplicationStatistics\f[R]
T}@T{
\(ga\-Xlog:gc+stringdedup*=debug
T}@T{
\(ga کاربرد ندارد
T}
T{
\f[CR]PrintTenuringDistribution\f[R]
T}@T{
\f[CR]\-Xlog:gc+age*=\f[R]\f[I]level\f[R]
T}@T{
از یک \f[I]level\f[R] با مقدار \f[CR]debug\f[R] برای مرتبط‌ترین اطلاعات،
یا یک \f[I]level\f[R] با مقدار \f[CR]trace\f[R] برای تمام آنچه که توسط
\f[CR]PrintTenuringDistribution\f[R] لاگ می‌شد، استفاده کنید.
T}
T{
\f[CR]UseGCLogFileRotation\f[R]
T}@T{
کاربرد ندارد
T}@T{
آنچه که برای \f[CR]PrintTenuringDistribution\f[R] لاگ می‌شد.
T}
.TE.SS تبدیل پرچم‌های ثبت گزارش زمان اجرا به Xlog
این پرچم‌های قدیمی دیگر شناخته‌شده نیستند و در صورت استفادهٔ مستقیم موجب خطا خواهند شد.
به‌جای آن‌ها از معادل ثبت گزارش یکپارچه استفاده کنید.
.PP
نگاشت پرچم‌های ثبت گزارش زمان اجرا به پیکربندی Xlog
.TS
tab(@);
lw(15.0n) lw(20.2n) lw(34.7n).
T{
پرچم قدیمی زمان اجرا
T}@T{
پیکربندی Xlog
T}@T{
توضیحات
T}
_
T{
\f[CR]TraceExceptions\f[R]
T}@T{
\f[CR]\-Xlog:exceptions=info\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceClassLoading\f[R]
T}@T{
\f[CR]\-Xlog:class+load=\f[R]\f[I]level\f[R]
T}@T{
از \f[I]level\f[R]=\f[CR]info\f[R] برای اطلاعات عادی، یا از
\f[I]level\f[R]=\f[CR]debug\f[R] برای اطلاعات بیشتر استفاده کنید.
در نحو ثبت گزارش یکپارچه (Unified Logging)،‏ \f[CR]\-verbose:class\f[R] برابر با
\f[CR]\-Xlog:class+load=info,class+unload=info\f[R] است.
T}
T{
\f[CR]TraceClassLoadingPreorder\f[R]
T}@T{
\f[CR]\-Xlog:class+preorder=debug\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceClassUnloading\f[R]
T}@T{
\f[CR]\-Xlog:class+unload=\f[R]\f[I]level\f[R]
T}@T{
از \f[I]level\f[R]=\f[CR]info\f[R] برای اطلاعات عادی، یا از
\f[I]level\f[R]=\f[CR]trace\f[R] برای اطلاعات بیشتر استفاده کنید.
در نحو ثبت گزارش یکپارچه (Unified Logging)،‏ \f[CR]\-verbose:class\f[R] برابر با
\f[CR]\-Xlog:class+load=info,class+unload=info\f[R] است.
T}
T{
\f[CR]VerboseVerification\f[R]
T}@T{
\f[CR]\-Xlog:verification=info\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceClassPaths\f[R]
T}@T{
\f[CR]\-Xlog:class+path=info\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceClassResolution\f[R]
T}@T{
\f[CR]\-Xlog:class+resolve=debug\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceClassInitialization\f[R]
T}@T{
\f[CR]\-Xlog:class+init=info\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceLoaderConstraints\f[R]
T}@T{
\f[CR]\-Xlog:class+loader+constraints=info\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceClassLoaderData\f[R]
T}@T{
\f[CR]\-Xlog:class+loader+data=\f[R]\f[I]level\f[R]
T}@T{
از \f[I]level\f[R]=\f[CR]debug\f[R] برای اطلاعات عادی یا از
\f[I]level\f[R]=\f[CR]trace\f[R] برای اطلاعات بیشتر استفاده کنید.
T}
T{
\f[CR]TraceSafepointCleanupTime\f[R]
T}@T{
\f[CR]\-Xlog:safepoint+cleanup=info\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceSafepoint\f[R]
T}@T{
\f[CR]\-Xlog:safepoint=debug\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceMonitorInflation\f[R]
T}@T{
\f[CR]\-Xlog:monitorinflation=debug\f[R]
T}@T{
غیرقابل اعمال
T}
T{
\f[CR]TraceRedefineClasses\f[R]
T}@T{
\f[CR]\-Xlog:redefine+class*=\f[R]\f[I]level\f[R]
T}@T{
مقادیر \f[I]level\f[R]=\f[CR]info\f[R]،‏ \f[CR]debug\f[R] و \f[CR]trace\f[R]
به ترتیب حجم بیشتری از اطلاعات را ارائه می‌دهند.
T}
.TE.SS "مثال‌های کاربرد \-Xlog (\-Xlog Usage Examples)"
موارد زیر مثال‌هایی از کاربرد \f[CR]\-Xlog\f[R] هستند.
.TP
\f[CR]\-Xlog\f[R]
همه پیام‌ها را با استفاده از سطح \f[CR]info\f[R] همراه با تزیینات \f[CR]uptime\f[R]، \f[CR]levels\f[R] و
\f[CR]tags\f[R] در \f[CR]stdout\f[R] ثبت می‌کند.
این معادل استفاده از دستور زیر است:
.RS
.RS
.PP
\f[CR]\-Xlog:all=info:stdout:uptime,levels,tags\f[R]
.RE
.RE
.TP
\f[CR]\-Xlog:gc\f[R]
پیام‌های دارای برچسب \f[CR]gc\f[R] را با استفاده از سطح \f[CR]info\f[R]
در \f[CR]stdout\f[R] ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R] همچنان برقرار است.
.TP
\f[CR]\-Xlog:gc,safepoint\f[R]
پیام‌هایی را که دارای یکی از برچسب‌های \f[CR]gc\f[R] یا
\f[CR]safepoint\f[R] هستند، هر دو با استفاده از سطح \f[CR]info\f[R] و با تزیینات پیش‌فرض،
در \f[CR]stdout\f[R] ثبت می‌کند.
پیام‌هایی که هم‌زمان دارای هر دو برچسب \f[CR]gc\f[R] و \f[CR]safepoint\f[R]
باشند ثبت نخواهند شد.
.TP
\f[CR]\-Xlog:gc+ref=debug\f[R]
پیام‌هایی را که هم‌زمان دارای هر دو برچسب \f[CR]gc\f[R] و \f[CR]ref\f[R] هستند،
با استفاده از سطح \f[CR]debug\f[R] و با تزیینات پیش‌فرض در \f[CR]stdout\f[R] ثبت می‌کند.
پیام‌هایی که فقط دارای یکی از این دو برچسب باشند ثبت نخواهند شد.
.TP
\f[CR]\-Xlog:gc=debug:file=gc.txt:none\f[R]
پیام‌های دارای برچسب \f[CR]gc\f[R] را با استفاده از سطح
\f[CR]debug\f[R] بدون هیچ‌گونه تزییناتی در فایلی به نام \f[CR]gc.txt\f[R]
ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R] همچنان برقرار است.
.TP
\f[CR]\-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pid:filecount=5,filesize=1024\f[R]
پیام‌های دارای برچسب \f[CR]gc\f[R] را با استفاده از سطح
\f[CR]trace\f[R] در یک مجموعه فایل چرخشی با ۵ فایل و اندازهٔ ۱
مگابایت با نام پایهٔ \f[CR]gctrace.txt\f[R] ثبت کرده و از تزیینات
\f[CR]uptimemillis\f[R] و \f[CR]pid\f[R] استفاده می‌کند.
.RS
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R] همچنان برقرار است.
.RE
.TP
\f[CR]\-Xlog:gc::uptime,tid\f[R]
پیام‌های دارای برچسب \f[CR]gc\f[R] را با استفاده از سطح پیش‌فرض
\(aqinfo\(aq در خروجی پیش‌فرض \f[CR]stdout\f[R] ثبت کرده و از
تزیینات \f[CR]uptime\f[R] و \f[CR]tid\f[R] استفاده می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R] همچنان برقرار است.
.TP
\f[CR]\-Xlog:gc*=info,safepoint*=off\f[R]
پیام‌هایی را که دست‌کم دارای برچسب \f[CR]gc\f[R] هستند با استفاده از
سطح \f[CR]info\f[R] ثبت می‌کند، اما ثبت پیام‌های دارای برچسب
\f[CR]safepoint\f[R] را غیرفعال می‌سازد.
پیام‌هایی که هم‌زمان دارای هر دو برچسب \f[CR]gc\f[R] و \f[CR]safepoint\f[R]
باشند ثبت نخواهند شد.
.TP
\f[CR]\-Xlog:disable \-Xlog:safepoint=trace:safepointtrace.txt\f[R]
تمامی گزارش‌گیری‌ها، از جمله هشدارها و خطاها را غیرفعال کرده و سپس
پیام‌های دارای برچسب \f[CR]safepoint\f[R] را با سطح \f[CR]trace\f[R] در
فایل \f[CR]safepointtrace.txt\f[R] فعال می‌کند.
پیکربندی پیش‌فرض اعمال نمی‌شود، زیرا خط فرمان
با \f[CR]\-Xlog:disable\f[R] آغاز شده است.
.SS "مثال‌های پیچیده کاربرد \-Xlog (Complex \-Xlog Usage Examples)"
موارد زیر چند مثال پیچیده از به‌کارگیری گزینهٔ
\f[CR]\-Xlog\f[R] را شرح می‌دهد.
.TP
\f[CR]\-Xlog:gc+class*=debug\f[R]
پیام‌هایی را که دست‌کم دارای برچسب‌های \f[CR]gc\f[R] و \f[CR]class\f[R]
هستند با استفاده از سطح \f[CR]debug\f[R] در \f[CR]stdout\f[R] ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R] همچنان برقرار است.
.TP
\f[CR]\-Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt\f[R]
پیام‌هایی را که دست‌کم دارای برچسب‌های \f[CR]gc\f[R] و \f[CR]meta\f[R]
هستند با استفاده از سطح \f[CR]trace\f[R] در فایل
\f[CR]metatrace.txt\f[R] ثبت می‌کند، اما ثبت همهٔ پیام‌های دارای برچسب
\f[CR]class\f[R] را غیرفعال می‌سازد.
پیام‌هایی که دارای برچسب‌های \f[CR]gc\f[R]، \f[CR]meta\f[R] و
\f[CR]class\f[R] باشند ثبت نمی‌شوند، زیرا \f[CR]class*\f[R] بر روی خاموش (off) تنظیم شده است.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R]، به استثنای مواردی که شامل
\f[CR]class\f[R] هستند برقرار است.
.TP
\f[CR]\-Xlog:gc+meta=trace\f[R]
پیام‌هایی را که دقیقاً دارای برچسب‌های \f[CR]gc\f[R] و \f[CR]meta\f[R]
هستند با استفاده از سطح \f[CR]trace\f[R] در \f[CR]stdout\f[R] ثبت می‌کند.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R] همچنان برقرار است.
.TP
\f[CR]\-Xlog:gc+class+heap*=debug,meta*=warning,threads*=off\f[R]
پیام‌هایی را که دست‌کم دارای برچسب‌های \f[CR]gc\f[R]، \f[CR]class\f[R] و
\f[CR]heap\f[R] هستند با استفاده از سطح \f[CR]trace\f[R] در
\f[CR]stdout\f[R] ثبت می‌کند، اما فقط پیام‌های دارای برچسب \f[CR]meta\f[R] را با آن
سطح ثبت می‌نماید.
پیکربندی پیش‌فرض برای تمامی پیام‌های دیگر در سطح
\f[CR]warning\f[R]، به استثنای مواردی که شامل
\f[CR]threads\f[R] هستند برقرار است..SH "اعتبارسنجی آرگومان‌های پرچم ماشین مجازی جاوا (VALIDATE JAVA VIRTUAL MACHINE FLAG ARGUMENTS)"
مقادیر ارائه‌شده به تمام پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) جهت اعتبارسنجی ارزیابی می‌شوند و در صورتی که مقدار ورودی نامعتبر یا خارج از محدوده باشد، پیام خطای مناسبی نمایش داده می‌شود.
.PP
چه این مقادیر به‌صورت ارگونومیک (ergonomic)، در خط فرمان، توسط یک ابزار ورودی یا از طریق APIها (برای نمونه، کلاس‌های موجود در بستهٔ
\f[CR]java.lang.management\f[R]) تعیین شده باشند، مقادیر ارائه‌شده برای تمامی پرچم‌های خط فرمان ماشین مجازی جاوا (JVM) اعتبارسنجی می‌شوند.
ارگونومی در «راهنمای تنظیم بازیافت حافظه ماشین مجازی هات‌اسپات ویرایش استاندارد پلتفرم جاوا» (Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide) شرح داده شده است.
.PP
محدوده و محدودیت‌ها چه هنگام مقداردهی تمام پرچم‌ها در زمان راه‌اندازی JVM و چه هنگام تغییر مقدار یک پرچم در حین اجرا (برای نمونه با استفاده از ابزار \f[CR]jcmd\f[R]) اعتبارسنجی می‌شوند.
اگر مقداری بررسی محدوده یا قید را نقض کند، JVM متوقف شده و یک پیام خطای مناسب روی جریان خطا چاپ می‌شود.
.PP
برای نمونه، اگر یک پرچم بررسی محدوده یا قید را نقض کند، JVM با یک خطا خارج می‌شود:
.IP
.EX
java \-XX:AllocatePrefetchStyle=5 \-version
intx AllocatePrefetchStyle=5 is outside the allowed range [ 0 ... 3 ]
Improperly specified VM option \(aqAllocatePrefetchStyle=5\(aq
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
.EE
.PP
پرچم \f[CR]\-XX:+PrintFlagsRanges\f[R] محدودهٔ تمام پرچم‌ها را چاپ می‌کند.
این پرچم امکان آزمایش خودکار پرچم‌ها را بر اساس مقادیر مشخص‌شده در محدوده‌ها فراهم می‌سازد.
برای پرچم‌هایی که محدودهٔ معینی دارند، نوع، نام و محدودهٔ واقعی در خروجی چاپ می‌شود.
.PP
برای نمونه:
.IP
.EX
intx   ThreadStackSize [ 0 ... 9007199254740987 ] {pd product}
.EE
.PP
برای پرچم‌هایی که محدودهٔ مشخصی ندارند، مقادیر در خروجی نمایش داده نمی‌شوند.
برای نمونه:
.IP
.EX
size_t NewSize         [   ...                  ] {product}
.EE
.PP
این موضوع به شناسایی پرچم‌هایی که نیاز به پیاده‌سازی دارند کمک می‌کند.
چارچوب آزمایش خودکار می‌تواند از پرچم‌هایی که مقداری نداشته و پیاده‌سازی نشده‌اند، صرف‌نظر کند.
.SH "صفحات بزرگ (LARGE PAGES)"
شما می‌توانید از صفحات بزرگ (large pages) که با عنوان huge pages نیز شناخته می‌شوند، به‌عنوان صفحات حافظه‌ای استفاده کنید که به‌طور قابل‌توجهی از اندازهٔ استاندارد صفحهٔ حافظه (که بسته به پردازنده و سیستم‌عامل متغیر است) بزرگ‌ترند.
صفحات بزرگ بافرهای ترجمهٔ آدرس پردازنده (Translation\-Lookaside Buffers یا TLB) را بهینه‌سازی می‌کنند.
.PP
بافر ترجمهٔ آدرس (TLB) یک حافظهٔ پنهان برای ترجمهٔ صفحات است که آخرین ترجمه‌های آدرس‌های مجازی به فیزیکیِ استفاده‌شده را در خود نگه می‌دارد.
یک TLB منبع سیستمی کمیابی است.
رخ دادن یک TLB miss می‌تواند هزینه‌بر باشد زیرا پردازنده ناچار است جدول سلسله‌مراتبی صفحات را بخواند که ممکن است به چندین بار دسترسی به حافظه نیاز داشته باشد.
با استفاده از صفحات حافظه با اندازهٔ بزرگ‌تر، یک مدخل واحد در TLB می‌تواند محدودهٔ بزرگ‌تری از حافظه را پوشش دهد.
این امر موجب کاهش فشار بر روی TLB می‌شود و برنامه‌های با مصرف حافظهٔ بالا ممکن است کارایی و عملکرد بهتری پیدا کنند.
.PP
با این حال، استفاده از صفحات بزرگ می‌تواند تأثیر منفی بر عملکرد سیستم بگذارد.
برای نمونه، هنگامی که مقدار زیادی از حافظه توسط یک برنامه پین (قفل) می‌شود، ممکن است کمبود حافظهٔ معمولی ایجاد کند و منجر به صفحه‌بندی بیش از حد در برنامه‌های دیگر شده و کل سیستم را کُند سازد.
همچنین، سیستمی که برای مدتی طولانی روشن بوده است ممکن است دچار تکه‌تکه‌شدگی (fragmentation) بیش از حد شود که می‌تواند تخصیص حافظهٔ کافی با صفحات بزرگ را غیرممکن کند.
هنگامی که این وضعیت رخ می‌دهد، سیستم‌عامل یا JVM به استفاده از صفحات معمولی بازمی‌گردند.
.PP
لینوکس و ویندوز از صفحات بزرگ پشتیبانی می‌کنند..SS "پشتیبانی از صفحات بزرگ در لینوکس (Large Pages Support for Linux)"
لینوکس از نسخهٔ 2.6 از صفحات بزرگ پشتیبانی می‌کند.
برای بررسی اینکه آیا محیط شما از صفحات بزرگ پشتیبانی می‌کند یا خیر، دستور زیر را امتحان کنید:
.IP
.EX
# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
\&...
Hugepagesize: 2048 kB
.EE
.PP
اگر خروجی شامل مواردی با پیشوند \(dqHuge\(dq باشد، سیستم شما از صفحات بزرگ پشتیبانی می‌کند.
این مقادیر ممکن است بسته به محیط متغیر باشند.
فیلد \f[CR]Hugepagesize\f[R] اندازهٔ پیش‌فرض صفحات بزرگ را در محیط شما نشان می‌دهد و سایر فیلدها جزئیات مربوط به صفحات بزرگِ این اندازه را نمایش می‌دهند.
کرنل‌های جدیدتر از چندین اندازهٔ مختلف برای صفحات بزرگ پشتیبانی می‌کنند.
برای فهرست کردن اندازه‌های پشتیبانی‌شدهٔ صفحات، این دستور را اجرا کنید:
.IP
.EX
# ls /sys/kernel/mm/hugepages/
hugepages\-1048576kB  hugepages\-2048kB
.EE
.PP
محیط بالا از صفحات بزرگ ۲ مگابایتی و ۱ گیگابایتی پشتیبانی می‌کند، اما باید پیکربندی شوند تا JVM بتواند از آن‌ها استفاده کند.
هنگام استفاده از صفحات بزرگ و فعال نکردن صفحات بزرگ شفاف (گزینهٔ \f[CR]\-XX:+UseTransparentHugePages\f[R])، تعداد صفحات بزرگ باید از پیش تخصیص داده شود.
برای مثال، برای فعال‌سازی ۸ گیگابایت حافظه با پشتیبانی صفحات بزرگ ۲ مگابایتی، با کاربر \f[CR]root\f[R] وارد شده و اجرا کنید:
.RS
.PP
\f[CR]# echo 4096 > /sys/kernel/mm/hugepages/hugepages\-2048kB/nr_hugepages\f[R]
.RE
.PP
همواره توصیه می‌شود پس از درخواست، مقدار \f[CR]nr_hugepages\f[R] را بررسی کنید تا مطمئن شوید کرنل توانسته است تعداد صفحات بزرگ درخواستی را تخصیص دهد.
.RS
.PP
\f[B]نکته:\f[R] مقادیر موجود در \f[CR]/proc\f[R] و \f[CR]/sys\f[R] پس از راه‌اندازی مجدد سیستم بازنشانی می‌شوند، بنابراین ممکن است بخواهید آن‌ها را در یک اسکریپت راه‌اندازی اولیه (به عنوان مثال، \f[CR]rc.local\f[R] یا \f[CR]sysctl.conf\f[R]) تنظیم کنید.
.RE
.PP
اگر پارامترهای کرنل سیستم‌عامل را برای فعال‌سازی استفاده از صفحات بزرگ پیکربندی کنید، فرایندهای جاوا ممکن است صفحات بزرگ را هم برای هیپ جاوا (Java heap) و هم برای سایر بخش‌های داخلی تخصیص دهند، به عنوان مثال:
.IP \(bu 2
حافظهٔ نهان کد (Code cache)
.IP \(bu 2
بیت‌مپ‌های علامت‌گذاری (Marking bitmaps)
.PP
در نتیجه، اگر پارامتر \f[CR]nr_hugepages\f[R] را به اندازهٔ هیپ جاوا تنظیم کنید، JVM همچنان ممکن است در تخصیص هیپ با استفاده از صفحات بزرگ با شکست مواجه شود، زیرا بخش‌های دیگری مانند حافظهٔ نهان کد ممکن است از قبل بخشی از صفحات بزرگ پیکربندی‌شده را مصرف کرده باشند.
.SS "پشتیبانی از صفحات بزرگ در ویندوز (Large Pages Support for Windows)"
برای استفاده از پشتیبانی صفحات بزرگ در ویندوز، مدیر سیستم ابتدا باید امتیازهای اضافی را به کاربری که برنامه را اجرا می‌کند اختصاص دهد:
.IP "1." 3
گزینهٔ \f[B]Control Panel\f[R]، سپس \f[B]Administrative Tools\f[R] و بعد از آن \f[B]Local Security Policy\f[R] را انتخاب کنید.
.IP "2." 3
بخش \f[B]Local Policies\f[R] و سپس \f[B]User Rights Assignment\f[R] را انتخاب کنید.
.IP "3." 3
روی \f[B]Lock pages in memory\f[R] دوبار کلیک کرده و سپس کاربران و/یا گروه‌ها را اضافه کنید.
.IP "4." 3
سیستم خود را مجدداً راه‌اندازی کنید.
.PP
توجه داشته باشید که این مراحل حتی در صورتی که مدیر سیستم برنامه را اجرا کند نیز لازم است، زیرا مدیران سیستم به طور پیش‌فرض امتیاز قفل کردن صفحات در حافظه را ندارند.
.SH "اشتراک داده‌های کلاس برنامه (APPLICATION CLASS DATA SHARING)"
قابلیت اشتراک داده‌های کلاس برنامه (AppCDS) کلاس‌های مورد استفادهٔ برنامه‌های شما را در یک فایل آرشیو ذخیره می‌کند.
از آنجا که این کلاس‌ها در قالبی ذخیره می‌شوند که بارگذاری آن‌ها بسیار سریع است (در مقایسه با کلاس‌های ذخیره‌شده در فایل JAR)، AppCDS می‌تواند زمان راه‌اندازی برنامه‌های شما را بهبود ببخشد.
علاوه بر این، AppCDS می‌تواند با به اشتراک‌گذاری بخش‌هایی از این کلاس‌ها در میان چندین فرایند، میزان مصرف حافظه در زمان اجرا را کاهش دهد.
.PP
کلاس‌ها در آرشیو CDS در قالبی بهینه‌سازی‌شده ذخیره می‌شوند که حدود ۲ تا ۵ برابر بزرگ‌تر از کلاس‌های ذخیره‌شده در فایل‌های JAR یا ایمیج زمان اجرای JDK است.
بنابراین، ایدهٔ خوبی است که فقط کلاس‌هایی را که واقعاً توسط برنامهٔ شما استفاده می‌شوند آرشیو کنید.
این کلاس‌ها معمولاً تنها بخش کوچکی از تمام کلاس‌های موجود هستند.
برای مثال، برنامهٔ شما ممکن است فقط از تعداد انگشت‌شماری از APIهای ارائه‌شده توسط یک کتابخانهٔ بزرگ استفاده کند..SS استفاده از بایگانی‌های CDS
به‌طور پیش‌فرض، در بیشتر توزیع‌های JDK، مگر اینکه \f[CR]\-Xshare:off\f[R]
مشخص شده باشد، JVM با یک بایگانی CDS پیش‌فرض راه‌اندازی می‌شود که
معمولاً در \f[CR]JAVA_HOME/lib/server/classes.jsa\f[R] (یا
\f[CR]JAVA_HOME\(rsbin\(rsserver\(rsclasses.jsa\f[R] در ویندوز)
قرار دارد.
این بایگانی شامل حدود ۱۳۰۰ کلاس از کتابخانه‌های اصلی است که توسط
بیشتر برنامه‌ها استفاده می‌شوند.
.PP
برای استفاده از CDS جهت مجموعه دقیق کلاس‌های استفاده‌شده توسط برنامه خود،
می‌توانید از گزینه \f[CR]\-XX:SharedArchiveFile\f[R] استفاده کنید
که ساختار کلی آن به این صورت است:
.RS
.PP
\f[CR]\-XX:SharedArchiveFile=<static_archive>:<dynamic_archive>\f[R]
.RE
.IP \(bu 2
بخش \f[CR]<static_archive>\f[R] جایگزین بایگانی پیش‌فرض CDS می‌شود.
.IP \(bu 2
بخش \f[CR]<dynamic_archive>\f[R] کلاس‌های اضافی را فراهم می‌کند که
می‌توانند علاوه بر کلاس‌های موجود در \f[CR]<static_archive>\f[R] بارگذاری شوند.
.IP \(bu 2
در ویندوز، نویسه جداکننده مسیر فوق \f[CR]:\f[R] باید با \f[CR];\f[R]
جایگزین شود.
.PP
نام‌های \(dqstatic\(dq (ایستا) و \(dqdynamic\(dq (پویا) به دلایل
تاریخی به‌کار رفته‌اند.
بایگانی پویا، اگرچه همچنان مفید است، نسبت به بایگانی CDS ایستا از
بهینه‌سازی‌های کمتری پشتیبانی می‌کند.
اگر مجموعه کامل بهینه‌سازی‌های CDS/AOT مد نظر است، استفاده از
کَش AOT که در ادامه توضیح داده شده را در نظر بگیرید.
.PP
ماشین مجازی جاوا (JVM) می‌تواند حداکثر از دو بایگانی استفاده کند.
برای استفاده از تنها یک \f[CR]<static_archive>\f[R]، می‌توانید بخش
\f[CR]<dynamic_archive>\f[R] را نادیده بگیرید:
.RS
.PP
\f[CR]\-XX:SharedArchiveFile=<static_archive>\f[R]
.RE
.PP
جهت سهولت کار، \f[CR]<dynamic_archive>\f[R] مکان
\f[CR]<static_archive>\f[R] را ذخیره می‌کند.
بنابراین، می‌توانید تنها با مشخص کردن مورد زیر، از ذکر \f[CR]<static_archive>\f[R]
صرف‌نظر کنید:
.RS
.PP
\f[CR]\-XX:SharedArchiveFile=<dynamic_archive>\f[R]
.RE
.SS ایجاد دستی بایگانی‌های CDS
بایگانی‌های CDS را می‌توان به‌صورت دستی با استفاده از چندین روش ایجاد کرد:
.IP \(bu 2
\f[CR]\-Xshare:dump\f[R]
.IP \(bu 2
\f[CR]\-XX:ArchiveClassesAtExit\f[R]
.IP \(bu 2
\f[CR]jcmd VM.cds\f[R]
.PP
یک عملیات مشترک در تمام این روش‌ها، یک \(dqاجرای آزمایشی\(dq (trial run) است
که در آن برنامه را یک بار اجرا می‌کنید تا کلاس‌هایی که باید در بایگانی ذخیره
شوند تعیین گردند.
.SS ایجاد یک فایل بایگانی CDS ایستا با \-Xshare:dump
مراحل زیر یک فایل بایگانی CDS ایستا ایجاد می‌کند که شامل تمام کلاس‌های
استفاده‌شده توسط برنامه \f[CR]test.Hello\f[R] است.
.IP "1." 3
ایجاد فهرستی از تمام کلاس‌های استفاده‌شده توسط برنامه \f[CR]test.Hello\f[R].
دستور زیر فایلی به نام \f[CR]hello.classlist\f[R] ایجاد می‌کند که
شامل فهرستی از تمامی کلاس‌های استفاده‌شده توسط این برنامه است:
.RS 4
.RS
.PP
\f[CR]java \-Xshare:off \-XX:DumpLoadedClassList=hello.classlist \-cp hello.jar test.Hello\f[R]
.RE
.PP
مسیر کلاس (classpath) مشخص‌شده با پارامتر \f[CR]\-cp\f[R] تنها باید
شامل فایل‌های JAR باشد.
.RE
.IP "2." 3
ایجاد یک بایگانی ایستا به نام \f[CR]hello.jsa\f[R] که شامل تمام
کلاس‌های موجود در \f[CR]hello.classlist\f[R] است:
.RS 4
.RS
.PP
\f[CR]java \-Xshare:dump \-XX:SharedArchiveFile=hello.jsa \-XX:SharedClassListFile=hello.classlist \-cp hello.jar\f[R]
.RE
.RE
.IP "3." 3
اجرای برنامه \f[CR]test.Hello\f[R] به همراه بایگانی
\f[CR]hello.jsa\f[R]:
.RS 4
.RS
.PP
\f[CR]java \-XX:SharedArchiveFile=hello.jsa \-cp hello.jar test.Hello\f[R]
.RE
.RE
.IP "4." 3
\f[B]اختیاری\f[R] بررسی اینکه آیا برنامه \f[CR]test.Hello\f[R] از
کلاس موجود در بایگانی اشتراکی \f[CR]hello.jsa\f[R] استفاده می‌کند یا خیر:
.RS 4
.RS
.PP
\f[CR]java \-XX:SharedArchiveFile=hello.jsa \-cp hello.jar \-Xlog:class+load test.Hello\f[R]
.RE
.PP
خروجی این دستور باید شامل متن زیر باشد:
.RS
.PP
\f[CR][info][class,load] test.Hello source: shared objects file\f[R]
.RE
.RE
.PP
به‌طور پیش‌فرض، هنگامی که گزینه \f[CR]\-Xshare:dump\f[R] استفاده می‌شود،
JVM در حالت صرفاً مفسر (interpreter\-only) اجرا می‌شود (همانند وضعیتی که گزینه
\f[CR]\-Xint\f[R] مشخص شده باشد).
این کار برای تولید خروجی قطعی و یکنواخت (deterministic) در فایل بایگانی
اشتراکی لازم است؛ یعنی دقیقاً همان بایگانی، بیت‌به‌بیت، با هر بار خروجی گرفتن
ایجاد خواهد شد.
با این حال، اگر خروجی قطعی لازم نباشد و فهرست کلاس (classlist) بزرگی دارید،
می‌توانید صراحتاً \f[CR]\-Xmixed\f[R] را به خط فرمان اضافه کنید تا
کامپایلر JIT فعال شود.
این کار روند ایجاد بایگانی را سرعت می‌بخشد..SS ایجاد فایل بایگانی پویای CDS با \-XX:ArchiveClassesAtExit
مزایای بایگانی‌های پویای CDS عبارتند از:
.IP \(bu 2
آن‌ها معمولاً فضای دیسک کمتری مصرف می‌کنند، زیرا نیازی به ذخیره کلاس‌هایی که از قبل در بایگانی ایستا قرار دارند، ندارند.
.IP \(bu 2
آن‌ها در مقایسه با بایگانی ایستای متناظر، با یک مرحله کمتر ایجاد می‌شوند.
.PP
مراحل زیر یک فایل بایگانی پویای CDS ایجاد می‌کنند که شامل کلاس‌های استفاده‌شده توسط برنامه \f[CR]test.Hello\f[R] است، به‌جز مواردی که از قبل در بایگانی پیش‌فرض CDS قرار دارند.
.IP "1." 3
ایجاد یک بایگانی پویای CDS به نام \f[CR]hello.jsa\f[R] که شامل تمام کلاس‌های موجود در \f[CR]hello.jar\f[R] است که توسط برنامه \f[CR]test.Hello\f[R] بارگذاری شده‌اند:
.RS 4
.RS
.PP
\f[CR]java \-XX:ArchiveClassesAtExit=hello.jsa \-cp hello.jar Hello\f[R]
.RE
.RE
.IP "2." 3
اجرای برنامه \f[CR]test.Hello\f[R] با بایگانی اشتراکی \f[CR]hello.jsa\f[R]:
.RS 4
.RS
.PP
\f[CR]java \-XX:SharedArchiveFile=hello.jsa \-cp hello.jar test.Hello\f[R]
.RE
.RE
.IP "3." 3
\f[B]اختیاری\f[R] مرحله ۴ از بخش قبلی را تکرار کنید تا مطمئن شوید برنامه \f[CR]test.Hello\f[R] از کلاس موجود در بایگانی اشتراکی \f[CR]hello.jsa\f[R] استفاده می‌کند.
.PP
همچنین می‌توان یک بایگانی پویای CDS را با یک بایگانی ایستای غیرپیش‌فرض CDS ایجاد کرد.
به عنوان مثال،
.RS
.PP
\f[CR]java \-XX:SharedArchiveFile=base.jsa \-XX:ArchiveClassesAtExit=hello.jsa \-cp hello.jar Hello\f[R]
.RE
.PP
برای اجرای برنامه با استفاده از این بایگانی پویای CDS:
.RS
.PP
\f[CR]java \-XX:SharedArchiveFile=base.jsa:hello.jsa \-cp hello.jar Hello\f[R]
.RE
.PP
(در Windows، جداکننده مسیر \f[CR]:\f[R] در بالا باید با \f[CR];\f[R] جایگزین شود)
.PP
همان‌طور که در بالا ذکر شد، می‌توان از نام بایگانی ایستا صرف‌نظر کرد:
.RS
.PP
\f[CR]java \-XX:SharedArchiveFile=hello.jsa \-cp hello.jar Hello\f[R]
.RE
.SS ایجاد فایل‌های بایگانی CDS با jcmd
دو بخش قبلی برای ایجاد یک بایگانی CDS، نیازمند تغییر دادن اسکریپت راه‌اندازی برنامه هستند.
گاهی اوقات این کار ممکن است دشوار باشد؛ برای مثال، هنگامی که class path برنامه توسط روال‌های پیچیده‌ای تنظیم شده است.
.PP
دستور \f[CR]jcmd VM.cds\f[R] با اتصال به یک پردازه در حال اجرای JVM، روشی با تداخل کمتر را برای ایجاد یک بایگانی CDS فراهم می‌کند.
شما می‌توانید یک بایگانی ایستا:
.RS
.PP
\f[CR]jcmd <pid> VM.cds static_dump my_static_archive.jsa\f[R]
.RE
.PP
یا یک بایگانی پویا بسازید:
.RS
.PP
\f[CR]jcmd <pid> VM.cds dynamic_dump my_dynamic_archive.jsa\f[R]
.RE
.PP
برای استفاده از فایل بایگانی حاصل در اجراهای بعدی برنامه بدون تغییر اسکریپت راه‌اندازی برنامه، می‌توانید از روش زیر استفاده کنید:
.RS
.PP
\f[CR]env JAVA_TOOL_OPTIONS=\-XX:SharedArchiveFile=my_static_archive.jsa bash app_start.sh\f[R]
.RE
.PP
نکته: برای استفاده از \f[CR]jcmd <pid> VM.cds dynamic_dump\f[R]، پردازه JVM که با \f[CR]<pid>\f[R] مشخص شده است باید با \f[CR]\-XX:+RecordDynamicDumpInfo\f[R] راه‌اندازی شده باشد، که می‌توان آن را نیز با همان روش به اسکریپت راه‌اندازی برنامه ارسال کرد:
.RS
.PP
\f[CR]env JAVA_TOOL_OPTIONS=\-XX:+RecordDynamicDumpInfo bash app_start.sh\f[R]
.RE.SS ایجاد فایل آرشیو پویای CDS با \-XX:+AutoCreateSharedArchive
گزینه \f[CR]\-XX:+AutoCreateSharedArchive\f[R] روشی راحت‌تر برای ایجاد/استفاده
از آرشیوهای CDS است.
برخلاف روش‌های ایجاد دستی آرشیو CDS که در بخش قبلی شرح داده شد، با
\f[CR]\-XX:+AutoCreateSharedArchive\f[R] دیگر نیازی به یک اجرای آزمایشیِ
جداگانه نیست.
در عوض، می‌توانید همیشه برنامه را با همان خط فرمان اجرا کنید و به‌طور
خودکار از مزایای CDS بهره‌مند شوید.
.RS
.PP
\f[CR]java \-XX:+AutoCreateSharedArchive \-XX:SharedArchiveFile=hello.jsa \-cp hello.jar Hello\f[R]
.RE
.PP
اگر فایل آرشیو مشخص‌شده وجود داشته باشد و توسط همان نسخه از JDK ایجاد شده باشد،
به‌عنوان یک آرشیو پویا بارگذاری می‌شود؛ در غیر این صورت در زمان راه‌اندازی VM نادیده
گرفته خواهد شد.
.PP
در هنگام خروج VM، اگر فایل آرشیو مشخص‌شده وجود نداشته باشد، ایجاد خواهد شد.
اگر وجود داشته باشد اما با نسخه متفاوتی از JDK (البته پس از JDK 19) ایجاد شده باشد،
جایگزین خواهد شد.
در هر دو حالت، آرشیو آماده خواهد بود تا در راه‌اندازی بعدی JVM با همان خط فرمان
بارگذاری شود.
.PP
اگر فایل آرشیو مشخص‌شده وجود داشته باشد اما توسط نسخه‌ای از JDK قبل از JDK 19 ایجاد
شده باشد، نادیده گرفته خواهد شد: نه در زمان راه‌اندازی بارگذاری می‌شود و نه هنگام
خروج جایگزین می‌گردد.
.PP
توسعه‌دهندگان باید توجه داشته باشند که محتویات فایل آرشیو CDS مختص به هر بیلد
از JDK است.
بنابراین، اگر به بیلد متفاوتی از JDK مهاجرت کنید،
\f[CR]\-XX:+AutoCreateSharedArchive\f[R] به‌طور خودکار آرشیو را برای مطابقت
با JDK بازسازی خواهد کرد.
اگر قصد دارید از این ویژگی همراه با یک آرشیو موجود استفاده کنید، باید اطمینان
حاصل فرمایید که آرشیو حداقل با نسخه ۱۹ از JDK ایجاد شده باشد.
.SS محدودیت‌های Class Path و Module Path
.IP \(bu 2
نه مسیر کلاس (\f[CR]\-classpath\f[R] و \f[CR]\-Xbootclasspath/a\f[R])
و نه مسیر ماژول (\f[CR]\-\-module\-path\f[R]) نمی‌توانند شامل دایرکتوری‌های
غیرخالی باشند.
.IP \(bu 2
تنها فایل‌های JAR ماژولار در \f[CR]\-\-module\-path\f[R] پشتیبانی می‌شوند.
ماژول‌های بازشده (Exploded modules) پشتیبانی نمی‌شوند.
.IP \(bu 2
مسیر کلاسی که در زمان ایجاد آرشیو استفاده شده است باید با مسیر کلاسی که در زمان
اجرا استفاده می‌شود یکسان باشد (یا پیشوندی از آن باشد).
(هیچ الزامی از این دست برای مسیر ماژول وجود ندارد.)
.IP \(bu 2
اگر هر یک از فایل‌های JAR در مسیر کلاس یا مسیر ماژول پس از تولید آرشیو اصلاح شوند،
آرشیو CDS بارگذاری نخواهد شد.
.SS گزینه‌های مرتبط با ماژول
گزینه‌های زیر در رابطه با ماژول‌ها توسط CDS پشتیبانی می‌شوند:
\f[CR]\-\-module\-path\f[R]، \f[CR]\-\-module\f[R]،
\f[CR]\-\-add\-modules\f[R] و \f[CR]\-\-enable\-native\-access\f[R].
.PP
مقادیر این گزینه‌ها (در صورت تعیین شدن)، باید هنگام ایجاد و استفاده از آرشیو
CDS یکسان باشند.
در غیر این صورت، چنانچه هر یک از این گزینه‌ها تطابق نداشته باشند، آرشیو CDS ممکن
است به‌طور جزئی یا کامل غیرفعال شود که منجر به کاهش کارایی خواهد شد.
.IP \(bu 2
اگر گزینه \f[CR]AOTClassLinking\f[R] (به زیر مراجعه کنید) در حین ایجاد آرشیو
CDS فعال \f[I]بوده باشد\f[R]، آرشیو CDS قابل استفاده نخواهد بود و پیام خطای زیر
چاپ می‌شود:
.RS 2
.PP
\f[CR]CDS archive has aot\-linked classes. It cannot be used when archived full module graph is not used\f[R]
.RE
.IP \(bu 2
اگر گزینه \f[CR]AOTClassLinking\f[R] در حین ایجاد آرشیو CDS فعال
\f[I]نبوده باشد\f[R]، آرشیو CDS قابل استفاده است، اما ویژگی \(dqarchived module graph\(dq
غیرفعال خواهد شد.
این امر می‌تواند به افزایش زمان راه‌اندازی منجر شود.
.PP
برای عیب‌یابی مشکلات مربوط به گزینه‌های AOT، می‌توانید \f[CR]\-Xlog:aot\f[R] را
به آرگومان‌های VM برنامه اضافه کنید.
به‌عنوان مثال، اگر در حین ایجاد آرشیو \f[CR]\-\-add\-modules jdk.jconsole\f[R] مشخص
شده باشد و در زمان اجرا \f[CR]\-\-add\-modules jdk.incubator.vector\f[R] مشخص گردد،
پیام‌های زیر لاگ خواهند شد:
.PP
\f[CR]Mismatched values for property jdk.module.addmods\f[R]
.PP
\f[CR]runtime jdk.incubator.vector dump time jdk.jconsole\f[R]
.PP
\f[CR]subgraph jdk.internal.module.ArchivedBootLayer cannot be used because full module graph is disabled\f[R]
.PP
اگر هر یک از گزینه‌های VM شامل \f[CR]\-\-upgrade\-module\-path\f[R]،
\f[CR]\-\-patch\-module\f[R] یا \f[CR]\-\-limit\-modules\f[R] مشخص شده باشند،
CDS غیرفعال می‌شود.
این بدان معناست که JVM بدون بارگذاری هیچ آرشیو CDSای اجرا خواهد شد.
علاوه بر این، اگر تلاش کنید با مشخص کردن هر یک از این ۳ گزینه یک آرشیو CDS
ایجاد کنید، JVM خطایی را گزارش خواهد کرد..SH "حافظه نهان پیش‌ازموعد (AHEAD\-OF\-TIME CACHE)"
سامانه JDK از بهینه‌سازی‌های پیش‌از‌موعد (AOT) که می‌توانند پیش از اجرای برنامه انجام شوند، پشتیبانی می‌کند.
یک نمونه Class Data Sharing (CDS) است (همان‌طور که در بالا توضیح داده شد) که کلاس‌ها را پیش از موعد تجزیه می‌کند.
بهینه‌سازی‌های AOT می‌توانند عملکرد راه‌اندازی (start\-up) و گرم‌شدن (warm\-up) برنامه‌های Java را بهبود بخشند.
.PP
حافظه نهان پیش‌از‌موعد (AOT cache) یک نگه‌دارنده است که در JDK 24 برای ذخیره‌سازی دست‌ساخته‌های تولیدشده توسط بهینه‌سازی‌های AOT معرفی شده است.
حافظه نهان AOT در حال حاضر شامل کلاس‌های Java و اشیاء حافظه هیپ (heap) است.
در نگارش‌های آینده JDK، ممکن است حافظه نهان AOT شامل دست‌ساخته‌های بیشتری مانند پروفایل‌های اجرا و متدهای کامپایل‌شده نیز باشد.
.PP
یک حافظه نهان AOT مختص ترکیبی از موارد زیر است:
.IP \(bu 2
یک برنامه خاص (همان‌طور که توسط \f[CR]\-classpath\f[R]، \f[CR]\-jar\f[R] یا \f[CR]\-\-module\-path\f[R] مشخص شده است).
.IP \(bu 2
یک نگارش خاص از JDK.
.IP \(bu 2
یک سیستم‌عامل و معماری پردازنده (CPU) خاص.
.PP
در صورت تغییر هر یک از موارد بالا، باید حافظه نهان AOT را دوباره بسازید.
.PP
استقرار حافظه نهان AOT به سه مرحله تقسیم می‌شود:
.IP \(bu 2
\f[B]آموزش (Training):\f[R] ما برنامه را با یک بار کاری نمونه اجرا می‌کنیم تا داده‌های آماری لازم برای مشخص کردن دست‌ساخته‌هایی که باید در حافظه نهان AOT گنجانده شوند را جمع‌آوری کنیم.
داده‌ها در یک فایل \f[I]AOT Configuration\f[R] ذخیره می‌شوند.
.IP \(bu 2
\f[B]سرهم‌بندی (Assembly):\f[R] ما از فایل پیکربندی AOT برای تولید یک حافظه نهان AOT استفاده می‌کنیم.
.IP \(bu 2
\f[B]عملیات (Production):\f[R] ما برنامه را همراه با حافظه نهان AOT برای دستیابی به عملکرد بهتر در راه‌اندازی و گرم‌شدن اجرا می‌کنیم.
.PP
حافظه نهان AOT می‌تواند با گزینه‌های خط فرمان زیر استفاده شود:
.TP
\f[CR]\-XX:AOTCache=\f[R]\f[I]cachefile\f[R]
مکان فایل حافظه نهان AOT را مشخص می‌کند.
پسوند استاندارد برای \f[I]cachefile\f[R] برابر با \f[CR].aot\f[R] است.
این گزینه نمی‌تواند همراه با \f[CR]\-XX:AOTCacheOutput\f[R] استفاده شود.
.RS
این گزینه با مقادیر \f[CR]on\f[R]، \f[CR]create\f[R] یا \f[CR]auto\f[R] (پیش‌فرض) در تنظیمات \f[CR]AOTMode\f[R] سازگار است.
فایل \f[I]cachefile\f[R] در حالت‌های AOT با مقادیر \f[CR]on\f[R] و \f[CR]auto\f[R] خوانده می‌شود و در حالت \f[CR]off\f[R] نادیده گرفته می‌شود.
فایل \f[I]cachefile\f[R] توسط حالت AOT با مقدار \f[CR]create\f[R] نوشته می‌شود.
در این صورت، این گزینه معادل با \f[CR]\-XX:AOTCacheOutput=\f[R]\f[I]cachefile\f[R] خواهد بود.
.RE
.TP
\f[CR]\-XX:AOTCacheOutput=\f[R]\f[I]cachefile\f[R]
مکان فایل حافظه نهان AOT را برای نوشتن مشخص می‌کند.
پسوند استاندارد برای \f[I]cachefile\f[R] برابر با \f[CR].aot\f[R] است.
این گزینه نمی‌تواند همراه با \f[CR]\-XX:AOTCache\f[R] استفاده شود.
.RS
این گزینه با مقادیر \f[CR]record\f[R]، \f[CR]create\f[R] یا \f[CR]auto\f[R] (پیش‌فرض) در تنظیمات \f[CR]AOTMode\f[R] سازگار است.
.RE
.TP
\f[CR]\-XX:AOTConfiguration=\f[R]\f[I]configfile\f[R]
فایل پیکربندی AOT را برای نوشتن یا خواندن توسط JVM مشخص می‌کند.
پسوند استاندارد برای \f[I]configfile\f[R] برابر با \f[CR].aotconfig\f[R] است.
.RS
این گزینه با مقادیر \f[CR]record\f[R]، \f[CR]create\f[R] یا \f[CR]auto\f[R] (پیش‌فرض) در تنظیمات \f[CR]AOTMode\f[R] سازگار است.
فایل \f[I]configfile\f[R] توسط حالت AOT با مقدار \f[CR]create\f[R] خوانده شده و توسط سایر حالت‌های مرتبط نوشته می‌شود.
اگر حالت AOT برابر با \f[CR]auto\f[R] باشد، گزینه \f[CR]AOTCacheOutput\f[R] نیز باید مشخص شده باشد.
.RE
.TP
\f[CR]\-XX:AOTMode=\f[R]\f[I]mode\f[R]
حالت AOT را برای این اجرا تعیین می‌کند.
مقدار \f[I]mode\f[R] باید یکی از موارد زیر باشد: \f[CR]auto\f[R]، \f[CR]off\f[R]، \f[CR]record\f[R]، \f[CR]create\f[R] یا \f[CR]on\f[R].
.IP \(bu 2
\f[CR]auto\f[R]: این حالت پیش‌فرض AOT است و در صورتی که گزینه \f[CR]\-XX:AOTMode\f[R] ارائه نشده باشد اعمال می‌شود.
این مقدار به‌طور خودکار حالت AOT را به شرح زیر روی \f[CR]record\f[R]، \f[CR]on\f[R] یا \f[CR]off\f[R] تنظیم می‌کند:
.RS 2
.IP \(bu 2
اگر \f[CR]\-XX:AOTCacheOutput=\f[R]\f[I]cachefile\f[R] مشخص شده باشد، حالت AOT به \f[CR]record\f[R] تغییر می‌یابد (یک اجرای آموزشی، به همراه عملیات بعدی \f[CR]create\f[R]).
.IP \(bu 2
در غیر این صورت، اگر یک حافظه نهان AOT بتواند بارگیری شود، حالت AOT به \f[CR]on\f[R] تغییر می‌یابد (یک اجرای عملیاتی).
.IP \(bu 2
در غیر این صورت، حالت AOT به \f[CR]off\f[R] تغییر می‌یابد (یک اجرای عملیاتی بدون حافظه نهان AOT).
.RE
.IP \(bu 2
\f[CR]off\f[R]: از هیچ حافظه نهان AOT استفاده نمی‌شود.
سایر گزینه‌های خط فرمان مربوط به AOT نادیده گرفته می‌شوند.
.IP \(bu 2
\f[CR]record\f[R]: برنامه را در فاز آموزش اجرا می‌کند.
حداقل یکی از گزینه‌های \f[CR]\-XX:AOTConfiguration=\f[R]\f[I]configfile\f[R] و/یا \f[CR]\-XX:AOTCacheOutput=\f[R]\f[I]cachefile\f[R] باید مشخص شود.
اگر \f[CR]\-XX:AOTConfiguration=\f[R]\f[I]configfile\f[R] مشخص شده باشد، JVM داده‌های آماری را جمع‌آوری کرده و آن‌ها را در \f[I]configfile\f[R] ذخیره می‌کند.
اگر \f[CR]\-XX:AOTConfiguration=\f[R]\f[I]configfile\f[R] مشخص نشده باشد، JVM از یک نام فایل موقت استفاده می‌کند که ممکن است رشته \f[CR]AOTCacheOutput+\(dq.config\(dq\f[R] یا نام فایل موقت جدید و وابسته به پیاده‌سازی دیگری باشد.
اگر \f[CR]\-XX:AOTCacheOutput=\f[R]\f[I]cachefile\f[R] مشخص شده باشد، یک فرآیند دوم JVM برای انجام مرحله سرهم‌بندی اجرا می‌شود تا دست‌ساخته‌های بهینه‌سازی را در \f[I]cachefile\f[R] بنویسد.
.RS 2
.PP
گزینه‌های اضافی JVM را می‌توان با استفاده از متغیر محیطی \f[CR]JDK_AOT_VM_OPTIONS\f[R]، با همان قالبی که برای متغیر محیطی \f[CR]JAVA_TOOL_OPTIONS\f[R] وجود دارد و توسط \f[B]JVMTI تعریف شده است\f[R]
[https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#tooloptions]، به فرآیند دوم JVM ارسال کرد.
.RE
.IP \(bu 2
\f[CR]create\f[R]: فاز سرهم‌بندی را انجام می‌دهد.
گزینه \f[CR]\-XX:AOTConfiguration=\f[R]\f[I]configfile\f[R] باید مشخص شده باشد.
سامانه JVM تاریخچه و آمارها را از \f[I]configfile\f[R] خوانده و دست‌ساخته‌های بهینه‌سازی را در \f[I]cachefile\f[R] می‌نویسد.
توجه داشته باشید که خود برنامه در این فاز اجرا نمی‌شود.
.IP \(bu 2
\f[CR]on\f[R]: برنامه را در فاز عملیات (Production) اجرا می‌کند.
اگر \f[CR]\-XX:AOTCache=\f[R]\f[I]cachefile\f[R] مشخص شده باشد، JVM تلاش می‌کند تا \f[I]cachefile\f[R] را به عنوان حافظه نهان AOT بارگیری کند.
در غیر این صورت، JVM تلاش می‌کند تا یک \f[I]default CDS archive\f[R] را از دایرکتوری نصب JDK به عنوان حافظه نهان AOT بارگیری کند.
.RS 2
.PP
بارگیری حافظه نهان AOT ممکن است به دلایل متعددی با شکست مواجه شود:
.IP \(bu 2
تلاش می‌کنید از حافظه نهان AOT با یک برنامه، نگارش JDK، یا سیستم‌عامل/معماری ناسازگار استفاده کنید.
.IP \(bu 2
فایل \f[I]cachefile\f[R] مشخص‌شده وجود ندارد یا در دسترس نیست.
.IP \(bu 2
از گزینه‌های ناسازگار JVM استفاده شده است (برای نمونه، برخی گزینه‌های خاص JVMTI).
.RS 2
.PP
از آنجا که حافظه نهان AOT یک قابلیت بهینه‌سازی است، هیچ تضمینی وجود ندارد که با تمام گزینه‌های ممکن JVM سازگار باشد.
برای مشاهده فهرستی از سناریوهایی که ممکن است با حافظه نهان AOT ناسازگار باشند، به بخش \f[B]Consistency of training and subsequent runs\f[R] در \f[B]JEP 483\f[R] [https://openjdk.org/jeps/483] مراجعه کنید.
.PP
این سناریوها معمولاً شامل تغییرات دلخواه روی کلاس‌ها برای مقاصد عیب‌یابی هستند و معمولاً به محیط‌های عملیاتی مربوط نمی‌شوند.
.RE
.PP
هنگامی که بارگیری حافظه نهان AOT با شکست مواجه می‌شود:
.IP \(bu 2
اگر \f[CR]AOTMode\f[R] در ابتدا روی \f[CR]auto\f[R] تنظیم شده بود، JVM به اجرای برنامه بدون استفاده از حافظه نهان AOT ادامه می‌دهد.
این حالت برای محیط‌های عملیاتی توصیه می‌شود، به‌ویژه زمانی که ممکن است کنترل کاملی روی خط فرمان نداشته باشید (مثلاً اسکریپت راه‌انداز برنامه شما ممکن است به کاربران اجازه دهد گزینه‌هایی را به خط فرمان اضافه کنند).
این امر به برنامه امکان می‌دهد به‌درستی به کار خود ادامه دهد، هرچند ممکن است از مزایای حافظه نهان AOT بهره‌مند نشود.
.IP \(bu 2
اگر \f[CR]AOTMode\f[R] روی \f[CR]on\f[R] باشد، JVM یک پیام خطا چاپ کرده و بلافاصله خارج می‌شود.
این حالت تنها باید به عنوان یک ابزار عیب‌یابی «شکست سریع» (\(dqfail\-fast\(dq) استفاده شود تا بررسی شود که آیا گزینه‌های خط فرمان شما با حافظه نهان AOT سازگار هستند یا خیر.
یک راهکار جایگزین، اجرای برنامه با \f[CR]\-XX:AOTMode=auto \-Xlog:aot\f[R] است تا بررسی شود که آیا حافظه نهان AOT قابل استفاده است یا خیر.
.RE
.TP
\f[CR]\-XX:+AOTClassLinking\f[R]
اگر این گزینه فعال باشد، JVM هنگام ایجاد حافظه نهان AOT بهینه‌سازی‌های پیشرفته‌تری (مانند حل پیش‌ازموعد دستورالعمل‌های invokedynamic) را انجام می‌دهد.
در نتیجه، برنامه شاهد بهبودهای بیشتری در عملکرد راه‌اندازی و گرم‌شدن خواهد بود.
با این حال، یک حافظه نهان AOT که با این گزینه ایجاد شده باشد، در صورت مشخص شدن برخی پارامترهای خاص خط فرمان در فاز عملیات، قابل استفاده نخواهد بود.
لطفاً برای بررسی دقیق‌تر \f[CR]\-XX:+AOTClassLinking\f[R] و محدودیت‌های آن، به \f[B]JEP 483\f[R] [https://openjdk.org/jeps/483] مراجعه کنید.
.RS
هنگامی که از \f[CR]\-XX:AOTMode\f[R] در خط فرمان \f[I]استفاده شود\f[R]، قابلیت \f[CR]AOTClassLinking\f[R] به‌طور خودکار فعال می‌شود.
برای غیرفعال کردن آن، باید صراحتاً گزینه \f[CR]\-XX:\-AOTClassLinking\f[R] را ارسال کنید.
هنگامی که از \f[CR]\-XX:AOTMode\f[R] در خط فرمان \f[I]استفاده نشود\f[R]، قابلیت \f[CR]AOTClassLinking\f[R] به‌طور پیش‌فرض غیرفعال است تا سازگاری کامل با گزینه‌های سنتی CDS مانند \(ga\-Xshare:dump فراهم شود.
.RE.PP
نخستین رخداد توالی ویژه \f[CR]%p\f[R] در \f[CR]*configfile*\f[R] و \f[I]cachefile\f[R] با شناسه فرایند (PID) فرایند JVM که در خط فرمان اجرا شده است جایگزین می‌شود، و به‌همین ترتیب نخستین رخداد \f[CR]%t\f[R] با برچسب زمان راه‌اندازی JVM جایگزین می‌گردد.
(پس از جایگزینی، نباید هیچ رخداد دیگری از \f[CR]%p\f[R] یا \f[CR]%t\f[R] باقی بماند تا از بروز مشکل در زیرفرایندها جلوگیری شود.)
برای مثال:
.RS
.PP
\f[CR]java \-XX:AOTConfiguration=foo%p.aotconfig \-XX:AOTCacheOutput=foo%p.aot \-cp foo.jar Foo\f[R]
.RE
.PP
دو فایل ایجاد خواهد کرد: \f[CR]foopid123.aotconfig\f[R] و
\f[CR]foopid123.aot\f[R]، که در آن‌ها \f[CR]123\f[R] شناسه فرایند JVM است
که برنامه \f[CR]Foo\f[R] را اجرا کرده است.
.SH "مثال‌های تنظیم کارایی (PERFORMANCE TUNING EXAMPLES)"
می‌توانید از گزینه‌های پیشرفته زمان اجرای جاوا برای بهینه‌سازی کارایی برنامه‌های خود استفاده کنید.
.SS "تنظیم برای توان عملیاتی بالاتر"
از دستورات و گزینه‌های پیشرفته زیر برای دستیابی به کارایی و توان عملیاتی (Throughput) بالاتر در برنامه خود استفاده کنید:
.RS
.PP
\f[CR]java \-server \-XX:+UseParallelGC \-XX:+UseLargePages \-Xmn10g  \-Xms26g \-Xmx26g\f[R]
.RE
.SS "تنظیم برای زمان پاسخ‌دهی کمتر"
از دستورات و گزینه‌های پیشرفته زیر برای دستیابی به زمان‌های پاسخ‌دهی کمتر در برنامه خود استفاده کنید:
.RS
.PP
\f[CR]java \-XX:+UseG1GC \-XX:MaxGCPauseMillis=100\f[R]
.RE
.SS "کوچک نگه‌داشتن Java Heap و کاهش ردپای حافظه پویای برنامه‌های تعبیه‌شده"
از گزینه‌های پیشرفته زمان اجرای زیر برای کوچک نگه‌داشتن Java heap و کاهش ردپای حافظه پویای برنامه‌های تعبیه‌شده (Embedded) استفاده کنید:
.RS
.PP
\f[CR]\-XX:MaxHeapFreeRatio=10 \-XX:MinHeapFreeRatio=5\f[R]
.RE
.RS
.PP
\f[B]نکته:\f[R] مقادیر پیش‌فرض برای این دو گزینه به‌ترتیب 70% و 40% است.
از آنجا که استفاده از این مقادیر کوچک ممکن است به بهای فدا کردن کارایی تمام شود، باید با کاهش این تنظیمات تا حد امکان بدون ایجاد افت کارایی غیرقابل‌قبول، مصرف حافظه را بهینه‌سازی کنید.
.RE
.SH "وضعیت خروج (EXIT STATUS)"
مقادیر خروج زیر معمولاً هنگامی توسط اجراکننده بازگردانده می‌شوند که با آرگومان‌های نادرست فراخوانی شود، یا خطاهای جدی و استثناهایی توسط JVM پرتاب شوند.
با این حال، یک برنامه جاوا می‌تواند با استفاده از فراخوانی API دستور \f[CR]System.exit(exitValue)\f[R] هر مقداری را برگرداند.
این مقادیر عبارتند از:
.IP \(bu 2
\f[CR]0\f[R]: اتمام موفقیت‌آمیز
.IP \(bu 2
\f[CR]>0\f[R]: خطایی رخ داده است