Kiến trúc JVM – kiến thức không thể bỏ qua

Bài viết được sự cho phép của tác giả Kiên Nguyễn

Đã là lập trình viên Java thì không thể không biết về JVM (Java Virtual Machine). Một chương trình Java sẽ được biên dịch ra byte code và thực thi với JRE (Java runtime environment)

Xem thêm nhiều việc làm Software Architect hấp dẫn trên TopDev

1. WORA – HAHA

Tất nhiên, chỉ WORA là có nghĩa WRITE ONE, RUN ANYWHERE. Một chương trình Java sau khi viết có thể chạy ở khắp mọi nơi. Chính Virtual Machine đã giúp ta điều này. Tất cả các class Java đều được compiler thành byte code, quẳng cho JVM thực thi.

2. JVM Architecture Diagram

Rất xin lỗi bạn đọc, những ai chưa từng tìm hiểu về kiến trúc JVM. Thề, mới đầu mình nhìn hình cũng ngộp cmn luôn. Ngáo ngơ bm.

Tuy nhiên, sau khi chia nhỏ thành các components để tìm hiểu và liên kết lại với nhau, kiến trúc JVM lại không quá phức tạp và khó hiểu. Hãy cùng tìm hiểu chứng năng và mục đích của từng components nhé.

3. Trời, vậy nó hoạt động như thế nào?

Như hình vẽ ta thấy 3 cục to to, đó chính là ba thành phần cơ bản nhất của JVM. Với tên như sau:

• Class Loader Subsystem
• Runtime Data Area
• Execution Engine

Kiến trúc này tương đương với kiến trúc “xay thịt heo”. Cũng 3 bước thuận theo lẽ tự nhiên.

• Class Loader Subsystem – chuẩn bị thịt (cạo lông, thui,).
• Runtime Data Area – chặt, thêm hành, tiêu, tỏi ớt, bla blo.
• Execution Engine – nấu.

Cách này có vẻ xem ra dễ hiểu và nhớ lâu hơn. Số ba, số ba, mỗi lần thắp hương 3 cây là có thể nhớ ngay tới kiến trúc JVM với 3 components chính.

Tiếp theo đây, hãy cùng phân tích sâu hơn về chức năng của từng thành phần này:

3.1 Class Loader Subsytem

3.1.1 Loading

Tất nhiên, nó là subsytem, chứ không phải sub thì đã là module lớn. =))). Việc loader này trong Java cũng có thứ tự ưu tiên nhất định. Rõ rồi, một application chúng ta làm cũng đủ thứ trong đó (extension, lib, jar, vân vân). Đây chính là lý do chúng ta cần Class Loader. Cũng giải thích luôn tại sao nó lại là bước đầu tiên.

Hãy cùng tìm hiểu bé đầu tiên.

3.1.1.1 Boot Strap ClassLoader

Responsible for loading classes from the bootstrap classpath, nothing but rt.jar. Highest priority will be given to this loader.

Boot Strap ClassLoader chỉ đơn giản là một bộ nạp các class core của Java (java.util, java.lang, …).

Không cần phải nhớ chi quá phức tạp. Boot Strap ClassLoader là nơi các class căn bản nhất được nạp vào. Những lớp này là một phần môi trường thực thi JRE. Tuy nhiên, những thành phần được nạp vào có thể khác nhau tùy thuộc vào JRE.

3.1.1.2 Extension ClassLoader.

Thằng này cũng đơn giản không kém. Nó thực hiện đúng như tên gọi. Extension (những thành phần mở rộng). Trong quá trình làm việc, ta sẽ cần thêm các file jar của các framework khác. Khi bỏ vào thư mục JAVA_HOME/jre/lib/ext , Extension ClassLoader sẽ chịu trách nhiệm load các class này.

3.1.1.3 Application ClassLoader.

Xong, khi load xong thành phần core, load xong extension thì việc cuối cùng là Load Application, những cái chúng ta viết ra.

Vậy là đã xong bước load. Sau khi load xong thì sẽ phải kiểm tra. Cùng tìm hiểu tiếp bước thứ 2: Linking.

3.1.2 Linking.

3.1.2.1 Verify.

Tên gọi y như chức năng, đây là nơi JVM sẽ kiểm tra bytecode đã được load từ bước thứ nhất. Tất nhiên, nếu kiểm tra có lỗi, sẽ trả ra lỗi ngay tại bước này (verification error).

3.1.2.2 Prepare.

Sau khi đã pass qua bước verify, bước tiếp theo sẽ load ra tất cả các biến static được khai báo, các giá trị này sẽ có giá trị default của chúng.

3.1.3 Initialization.

Đây là bước cuối cùng trong việc load class, tất cả các biến được khai báo là static sẽ được gán giá trị, các đoạn code được khai báo static sẽ thực thi.

Công việc khởi tạo class đã xong. Tiếp theo sẽ tới khu vực Runtime Data.

3.2 Runtime Data Area

Tới khu vực quan trọng rồi. Runtime Data chia thành 5 thành phần chính (components)

3.2.1.1 Method Area

3.2.1.2 Heap Area

All the class level data will be stored here, including static variables. There is only one method area per JVM, and it is a shared resource.

Tất cả các lớp (ở bất kì cấp nào) đều được lưu trữ ở đây, bao gồm luôn cả biến static. Method giống với heap, chỉ có duy nhất một phân vùng này trong JVM. Chia sẻ cho nhau.

Tất nhiên, khu vực heap sẽ lưu toàn bộ instance của biến (instance variables). Khai báo mảng (arrays) cũng được lưu trữ tại đây. Một điều đặc biệt là trong kiến trúc JVM thì chỉ có duy nhất một vùng heap.

Dữ liệu lưu ở heap được chia sẻ cho các luồng khác nhau. Do tính chất đa luồng truy cập của heap (multi threads), dữ liệu lưu ở đây không an toàn (có thể bị ghi đè, bị mất mát). Tựu chung, nếu muốn an toàn cho luồng (thread safe), hãy chú ý những gì được lưu ở khu vực này.

Since the Method and Heap areas share memory for multiple threads, the data stored is not thread-safe.

Cả method và Heap đều được chia sẻ cho nhiều threads, dữ liệu được lưu trữ ở đây không an toàn.

3.2.1.3 Stack Area

For every thread, a separate runtime stack will be created. For every method call, one entry will be made in the stack memory which is called as Stack Frame. All local variables will be created in the stack memory.

Đối với tất cả thread, khi runtime chương trình, stack sẽ được khởi tạo. Các method được gọi tới, nó sẽ được cung cấp một frame trên stack. Tất cả các biến địa phương (local variables) cũng sẽ được khởi tạo ở stack.

Đây chính là điểm khác biệt giữa Stack và Heap, xét về độ an toàn dữ liệu. Khi lưu ở Stack, sẽ ít có sự can thiệp, đơn giản ta có thể an tâm hơn khi làm việc với những gì được lưu ở stack.

3.2.1.4 PC Registers

Each thread will have separate PC Registers, to hold the address of current executing instruction once the instruction is executed the PC register will be updated with the next instruction.

Mỗi thread sẽ được lưu trữ ở PC Register, giữ địa chỉ thực thi hiện tại sau khi một lệnh khác đã được thực thi. Thông tin lệnh thực thi cũng sẽ được cập nhật.

3.2.1.5 Native Method stacks

Native Method Stack holds native method information. For every thread, a separate native method stack will be created.

Native Method Stack là nơi dữ toàn bộ thông tin của method. Đối với mỗi thread, nó sẽ tạo ra các method stack riêng biệt cho từng luồng.

3.3 Execution Engine

3.3.1 Interpreter

Tên nghe quen quá, hồi học kỹ thuật lập trình đây mà. Trình thông dịch –

Tất nhiên trình thông dịch (interpreter) cũng có điểm yếu của nó:

The disadvantage of the interpreter is that when one method is called multiple times, every time a new interpretation is required.

Điểm yếu của trình thông dịch là cứ mỗi lần method được gọi thì lại cần phải thông dịch lại.

3.3.2 IT Compiler

Vì đã học cả rồi nên mình không muốn nói sâu. Chỉ muốn phân tích thêm chút xíu về hiệu năng (performance) của compiler.

Trình biên dịch (compiler) khắc phục được điểm yếu của trình biên dịch. Một đoạn mã Java sau khi đã được biên dịch thì lần gọi sau sẽ không phải biên dịch mới.

This native code will be used directly for repeated method calls, which improve the performance of the system.

Đoạn chương trình đã được biên dịch sẽ được tái sử dụng khi method được goi, điều này giúp cải thiện hiệu năng của hệ thống.

3.3.3 Garbage Collector

Cuối cùng, thanh niên dọn rác. Cuộc đời chỉ có một nhiệm vụ cao cả là loại bỏ các object không được sử dụng (unreferenced objects). Ta có thể kích hoạt garbage bằng cách gọi System.gc ()

3.4 Java Native Interface (JNI)

Interface gốc này cung cấp cách thức giao tiếp, hỗ trợ JVM biên dịch bằng cách gọi các Native Method Libraries (phương thức gốc) của Java.

3.5 Native Method Libraries

This is a collection of the Native Libraries which is required for the Execution Engine.

Cuối cùng, Native Method Libraries là một tập các thư viện được yêu cầu cho trình thực thi (Execution Engine).

Bài viết gốc được đăng tải tại kieblog.vn

Có thể bạn quan tâm:

• 10 tips để trở thành Java Developer xịn hơn
• Java 9 và những điều cần biết
• 10 lí do để học Scala và FP

Xem thêm Việc làm IT hấp dẫn trên TopDev