Nếu ứng dụng của bạn không thể được làm cho vừa khớp với một vùng địa chỉ 32-bit, thì bạn có thể làm tăng nhiều vùng người dùng hơn bằng cách di chuyển đến thời gian chạy Java 64-bit. Nếu bạn đang chạy một hệ điều hành 64-bit, thì một thời gian chạy Java 64-bit sẽ mở cửa cho các vùng heap Java rất lớn và sẽ ít gặp vấn đề đau đầu liên quan đến-vùng-địa chỉ. Bảng 2 liệt kê các vùng người dùng hiện có sẵn với các hệ điều hành 64-bit:

Bảng 2. Các kích thước vùng người dùng trên các hệ điều hành 64-bit

Tuy nhiên, di chuyển đến 64-bit không phải là một giải pháp chung cho tất cả các vấn đề bộ nhớ riêng; bạn vẫn cần đủ bộ nhớ vật lý để duy trì tất cả dữ liệu của bạn. Nếu thời gian chạy Java của bạn không khớp với bộ nhớ vật lý thì hiệu năng sẽ kém đến mức không thể chấp nhận được vì hệ điều hành bị buộc phải quăng quật dữ liệu của thời gian chạy Java vào rồi lại ra khỏi vùng trao đổi. Vì cùng lý do tương tự, việc di chuyển đến 64-bit không phải là giải pháp lâu dài cho lỗi rò rỉ bộ nhớ — bạn đang chỉ tạo thêm nhiều vùng cho các lỗ rò, chỉ kéo dài thêm thời gian giữa các lần bắt buộc khởi động lại.

Không thể sử dụng mã riêng 32-bit với một thời gian chạy 64-bit; bất kỳ mã riêng nào: các thư viện JNI; các giao diện công cụ JVM (JVM Tool Interface-JVMTI); giao diện lược tả JVM (JVM Profiling Interface-JVMPI) và giao diện gỡ lỗi JVM (JVM Debug Interface-JVMDI) phải được biên dịch lại theo 64-bit. Hiệu năng của thời gian chạy 64-bit cũng có thể chậm hơn so với thời gian chạy 32-bit tương ứng trên phần cứng giống nhau. Thời gian chạy 64-bit sử dụng các con trỏ 64-bit (các tham khảo địa chỉ riêng), do đó, cùng đối tượng Java trên 64-bit chiếm nhiều vùng nhớ hơn so với một đối tượng có chứa cùng dữ liệu trên 32-bit. Các đối tượng lớn hơn có nghĩa là vùng heap lớn hơn để chứa cùng một lượng dữ liệu khi duy trì một hiệu năng GC tương tự, làm cho hệ điều hành và bộ nhớ đệm (caches) kém hiệu quả hơn. Đáng ngạc nhiên là, một vùng heap Java lớn hơn không nhất thiết có nghĩa là các thời gian tạm nghỉ của GC dài hơn, vì số lượng dữ liệu hoạt động trên vùng heap có thể không tăng lên và một số thuật toán GC có hiệu quả hơn với các vùng heap lớn hơn.

Một số thời gian chạy Java hiện đại có công nghệ để giảm bớt "sự phình to đối tượng" 64-bit và cải thiện hiệu năng. Những tính năng này hoạt động bằng cách sử dụng các tham chiếu ngắn hơn trên các thời gian chạy 64-bit. Điều này được gọi là các tham chiếu nén trong các bản triển khai thực hiện của IBM và các đối tượng nén trong bản triển khai thực hiện của Sun.

Một nghiên cứu so sánh về hiệu năng thời gian chạy Java vượt quá phạm vi của bài viết này, nhưng nếu bạn đang xem xét việc di chuyển tới 64-bit thì rất nên thử nghiệm ứng dụng của bạn trước để hiểu cách nó thực hiện. Vì việc thay đổi kích thước địa chỉ ảnh hưởng đến vùng heap Java, bạn sẽ cần phải điều chỉnh lại các giá trị cài đặt GC của mình trên kiến trúc mới thay vì chỉ mang sang các giá trị cài đặt hiện có của bạn.

Kết luận

Một sự hiểu biết về bộ nhớ riêng là cốt yếu khi bạn thiết kế và chạy nhiều ứng dụng Java lớn, nhưng nó thường bị xem nhẹ bởi vì nó gắn kết với phần cứng bụi bặm và các chi tiết hệ điều hành mà thời gian chạy Java đã được thiết kế để tránh cho chúng ta điều đó. JRE là một tiến trình riêng phải làm việc trong môi trường xác định bởi các chi tiết bụi bặm ấy. Để thu được hiệu năng tốt nhất từ ứng dụng Java của bạn, bạn phải hiểu ứng dụng ảnh hưởng đến việc sử dụng bộ nhớ riêng của thời gian chạy Java như thế nào.

Việc dùng hết bộ nhớ riêng có thể trông giống như việc dùng hết vùng heap Java, nhưng nó đòi hỏi một bộ công cụ khác để gỡ lỗi và giải quyết. Chìa khóa để sửa chữa các vấn đề bộ nhớ riêng là phải hiểu các hạn chế áp đặt bởi phần cứng và hệ điều hành mà các ứng dụng Java của bạn đang chạy trên đó và kết hợp điều này với kiến thức về các công cụ của hệ điều hành để giám sát việc sử dụng bộ nhớ riêng. Bằng cách làm theo cách tiếp cận này, bạn sẽ được trang bị để giải quyết một số vấn đề hiểm hóc nhất mà ứng dụng Java của bạn có thể đặt ra.