DEV Community: Ryan Zhi

Detailed Steps of JVM Object Creation Using the new Keyword in Java

Ryan Zhi — Tue, 11 Feb 2025 03:45:11 +0000

Class Loading Check
- Triggering Class Loading: If the target class has not yet been loaded, the JVM initiates the class loading process using a ClassLoader. This process typically involves the following phases:
  - Loading: Reads the bytecode from a file or network and converts it into JVM-internal data structures.
  - Verification: Ensures the bytecode complies with the JVM specifications to maintain security and integrity.
  - Preparation: Allocates memory for class variables and sets their default initial values.
  - Resolution: Converts symbolic references in the class into direct references. (Note that resolution may be delayed until the first time the class is used.)
  - Initialization: Executes the class constructor (<clinit>) to initialize static variables and execute static code blocks.
- After these steps, the class metadata (methods, fields, inheritance details, etc.) is loaded into the Method Area (or Metaspace), ensuring that the JVM can correctly refer to the class information during object creation.
Memory Allocation
- Allocation Strategies: The JVM allocates memory for the new object on the heap using different strategies depending on the state of the memory:
  - Bump-the-Pointer: This strategy is used when the heap is contiguous and well-organized. A pointer is simply moved to allocate a continuous block of memory.
  - Free List: When the heap is fragmented, the JVM maintains a free list—a list of available memory blocks—and searches for a block that is large enough for the new object.
- Concurrent Optimization:
  - CAS (Compare and Swap): In multi-threaded environments, CAS operations ensure that updates to the heap pointer are atomic. This prevents race conditions by allowing only one thread to successfully update the pointer at a time.
  - TLAB (Thread-Local Allocation Buffer): Each thread is provided with its own private memory buffer. This reduces contention between threads when allocating memory. However, if an object is too large (e.g., a large array), it might bypass the TLAB and be allocated directly in the shared heap space (such as the old generation).
Memory Space Initialization (Initialization to Zero Values)
- Once memory is allocated, the JVM initializes the entire memory region to zero (default values). This step is critical to ensure that all fields of the object start with a known state:
  - Primitive Types: For example, int is set to 0, boolean to false, long to 0L, float and double to 0.0, and char to '\u0000'.
  - Reference Types: All reference variables are initialized to null.
- This initialization prevents the object from containing random or undefined values before the explicit initialization code runs.
Object Header Setup
- Structure of the Object Header: The object header typically consists of two main components:
  - Mark Word: This field stores runtime data about the object, such as its lock state (e.g., no lock, biased lock, lightweight lock, heavyweight lock), GC generation age, and a lazily computed hashcode (if hashCode() is invoked).
  - Klass Pointer: This pointer references the class metadata in the Method Area, enabling the JVM to determine the object's type.
- Special Considerations: For array objects, the header also includes the length of the array.
Executing the Instance Initialization Method (<init> Method)
- Constructor Invocation: After setting up the memory and object header, the JVM calls the instance initialization method (the constructor, denoted by <init>) of the object.
- Initialization Process:
  - Default Initialization: The fields are already set to their default (zero) values.
  - Explicit Field Initialization: The JVM then applies any explicit field assignments provided in the class definition.
  - Initialization Blocks: Any non-static initialization blocks are executed.
  - Constructor Body: Finally, the code inside the constructor is executed to perform any additional setup required by the program.
  - Inheritance Handling: The initialization follows the order dictated by inheritance: the constructor of the parent class is executed first, followed by the child's constructor.
- Once the <init> method completes, the object is fully initialized and ready for use.

Conclusion:

When you invoke the new keyword in Java, the JVM executes the following sequence:

Class Loading Check: Loads, verifies, prepares, resolves, and initializes the class if it isn’t already loaded.
Memory Allocation: Allocates heap memory using strategies such as bump-the-pointer or free list, optimized for multi-threaded environments using CAS and TLAB.
Memory Initialization: Initializes the allocated memory to default zero values.
Object Header Setup: Configures the object's header with the Mark Word and Klass Pointer.
Instance Initialization: Executes the <init> method, following the proper initialization order, including parent class initialization.

类加载检查（Class Loading Check）
- 触发类加载：如果目标类尚未被加载，JVM 会通过类加载器（ClassLoader）启动类加载过程。这个过程通常包含以下阶段：
  - 加载（Loading）：从文件或网络中读取字节码，并转换为 JVM 内部数据结构。
  - 验证（Verification）：检查字节码是否符合 JVM 规范，确保安全性。
  - 准备（Preparation）：为类变量分配内存，并设置默认初始值。
  - 解析（Resolution）：将类中的符号引用转换为直接引用（这一步有时会延迟到首次使用时进行）。
  - 初始化（Initialization）：执行类构造器 <clinit> 方法，初始化静态变量和静态代码块。
- 经过上述过程，类的元数据（如方法、字段、继承关系等）会加载到方法区（或 Metaspace），确保后续对象创建能正确引用该类的信息。
内存分配（Memory Allocation）
- 分配策略： JVM 根据当前堆内存状况采用不同的内存分配方式：
  - 指针碰撞（Bump-the-Pointer）：适用于堆内存连续且规整的情况，直接通过移动指针来分配连续内存块。
  - 空闲列表（Free List）：当堆内存存在碎片化时，维护一张空闲内存块列表，在分配时查找足够大的内存块。
- 多线程并发优化：
  - CAS（Compare and Swap）操作：在多线程环境下，为确保内存分配过程中对堆指针的更新操作具有原子性和线程安全性，JVM 可能采用 CAS 原子操作。例如，当多个线程同时试图分配内存时，CAS 操作可以保证只有一个线程成功更新堆指针，从而防止竞争条件和数据不一致的问题。
  - TLAB（Thread-Local Allocation Buffer）：每个线程分配一个私有的内存缓冲区（TLAB），线程在自己的 TLAB 中快速分配内存，降低多线程竞争带来的性能开销。对于较大的对象（如大数组），可能会绕过 TLAB，直接在堆的公共区域（如老年代）中分配。
内存空间初始化（Initialization to Zero Values）
- 内存分配完成后，JVM 会将分配到的内存空间初始化为零值（默认值），以确保对象各字段在未显式赋值时不会包含未定义或随机的值。
- 基本数据类型：
  - int 初始化为 0
  - boolean 初始化为 false
  - long 初始化为 0L
  - float 和 double 初始化为 0.0
  - char 初始化为 '\u0000'
- 引用类型：初始化为 null。
设置对象头（Object Header Setup）
- 对象头结构：对象头主要包含两部分信息：
  - Mark Word：存储对象的运行时数据，如锁状态（无锁、偏向锁、轻量级锁、重量级锁）、GC 分代年龄等，以及在需要时延迟计算的哈希码（hashcode）。
  - Klass Pointer：指向方法区中该类的元数据，确定对象的类型。
- 特殊情况：对于数组对象，对象头中还会包含数组的长度信息。
执行实例初始化方法（方法）
- 调用构造方法：完成内存分配和对象头设置后，JVM 会调用该对象的实例初始化方法（构造函数 <init>）。
- 初始化过程：
  - 默认初始化：前面已将所有字段初始化为零值。
  - 显式赋值：根据代码中对实例变量的显式初始化赋值。
  - 初始化块：执行非静态代码块中的初始化逻辑。
  - 构造方法体：执行构造函数中定义的具体逻辑。
  - 继承关系处理：构造过程遵循“先初始化父类，再初始化子类”的顺序，确保继承体系中各层次的正确初始化。
- 当 <init> 方法执行完毕后，对象进入可用状态，并能被程序后续逻辑使用。

总结：

JVM 在通过 new 关键字创建新对象时，依次执行以下步骤：

类加载检查（如果类未加载，则完成加载、验证、准备、解析和初始化过程），
内存分配（采用指针碰撞或空闲列表策略，在多线程环境下通过 CAS 操作和 TLAB 优化分配），
内存空间初始化（初始化为零值以确保内存安全），
设置对象头（设置 Mark Word 和 Klass Pointer），
执行实例初始化方法（按继承顺序执行初始化块和构造方法）。

Performance Optimization for Java & MySQL: A Comprehensive Guide

Ryan Zhi — Fri, 07 Feb 2025 08:54:23 +0000

When working with MySQL in your Java applications, there are several layers at which you can optimize performance. In this post, I’ll cover key areas—from the database to your code, connection management, and even hardware/network considerations—to help you squeeze out every bit of performance.

I. Database-Level Optimizations

1. Index Optimization

Create the Right Indexes

Indexes are the cornerstone of fast queries. You should:

Index Frequently Queried Columns:

If you often filter on fields in the WHERE clause—like a username in a users table—ensure you have an index on that column.
Design Composite Indexes Carefully:

For example, if you frequently query an orders table by both order date and order amount, consider a composite index such as:

  CREATE INDEX idx_order_date_amount ON orders(order_date, order_amount);

Order matters here—place the most commonly filtered column first.

Avoid Over-Indexing

While indexes speed up reads, they can slow down writes (inserts, updates, and deletes) because the indexes need to be maintained. Avoid adding indexes to columns that rarely appear in query conditions or have low cardinality (e.g., a gender field with only “M” and “F”).

Regular Index Maintenance

Over time, indexes can become fragmented. Running commands like OPTIMIZE TABLE periodically can help keep your indexes performing well—but schedule these during off-peak hours if your table is large.

2. Query Optimization

Write Efficient Queries

Avoid SELECT *: Specify only the columns you need. For instance, if you only require the username and email, use:

  SELECT username, email FROM users;

Use Proper Joins: When joining multiple tables, make sure you join on indexed columns to avoid full table scans.

  SELECT o.order_id, u.username
  FROM orders o
  JOIN users u ON o.user_id = u.user_id;

Use Views and Stored Procedures When Appropriate

For complex queries, consider encapsulating the logic in a view or stored procedure. This can reduce round trips between your application and the database and allow MySQL to optimize the execution plan better.

3. Table Design Optimization

Table Partitioning & Splitting

Horizontal Splitting:

If you have a table with massive amounts of data, consider splitting it by ranges (e.g., by date or by user region).
Vertical Splitting:

Separate infrequently accessed columns into another table, reducing the size of the primary table.

Choose Appropriate Data Types

Opt for data types that match your data. For example, for binary states (yes/no), use TINYINT rather than VARCHAR. For dates, use DATE or DATETIME rather than storing dates as strings.

Partition Large Tables

If you have enormous tables, consider using MySQL’s partitioning feature. For example, partitioning a log table by date means that queries for a specific date only scan a single partition rather than the entire table.

II. Code-Level Optimizations

1. Reduce Unnecessary Queries

Cache Query Results

For data that doesn’t change often (e.g., configuration settings or lookup tables), cache the results in memory. Tools like Ehcache or Redis can significantly reduce load on your database.

Batch Your Queries

When you need to retrieve multiple records, avoid looping over single queries. Instead, use batch queries:

SELECT * FROM users WHERE user_id IN (1, 2, 3, 4);

2. Use Transactions Wisely

Keep Transactions Short

Limit the scope of your transactions to the minimum necessary work. This reduces lock contention and improves overall throughput.

Select the Right Isolation Level

MySQL’s default REPEATABLE READ isolation level may be overkill in some cases. If your application can tolerate it, consider lowering the isolation level to READ COMMITTED to improve performance.

3. Use Prepared Statements

Prepared statements not only help prevent SQL injection attacks but also improve performance by reusing the compiled SQL execution plan. For example:

String sql = "INSERT INTO users (username, email) VALUES (?, ?)";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, "username");
pstmt.setString(2, "email");
pstmt.executeUpdate();

III. Connection Management

1. Use a Connection Pool

Choosing a Connection Pool

Popular Java connection pools include DBCP, C3P0, and HikariCP. HikariCP is known for its high performance:

HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/mydb");
config.setUsername("root");
config.setPassword("password");
HikariDataSource dataSource = new HikariDataSource(config);

Configure Pool Parameters

Tweak parameters like maximumPoolSize (the maximum number of connections) and idleTimeout (to release idle connections) based on your workload and server capabilities.

2. Properly Use and Release Connections

Always close your connections after use to prevent leaks. The try-with-resources statement in Java is a great way to ensure this:

try (Connection connection = dataSource.getConnection();
     Statement statement = connection.createStatement();
     ResultSet resultSet = statement.executeQuery("SELECT * FROM users")) {
    while (resultSet.next()) {
        // Process results
    }
} catch (SQLException e) {
    e.printStackTrace();
}

IV. Hardware and Network Optimizations

1. Hardware Upgrades

Increase Memory:

More RAM means MySQL can cache more data, reducing the need to hit disk.
Use SSDs:

SSDs offer much faster read/write speeds compared to traditional HDDs, cutting down I/O bottlenecks.

2. Network Optimization

Reduce Latency:

Ensure your database and application servers are on a fast, reliable network. Consider co-locating them or using a high-speed network setup.
Proper Port Configuration:

Make sure that MySQL is configured on a dedicated port with the proper firewall settings to minimize network contention.

In-depth Interview Questions on Distributed Locks and Thread Pools

Ryan Zhi — Wed, 05 Feb 2025 13:02:09 +0000

Distributed Locks

Distributed Lock Principles

Distributed locks are typically implemented using Redis with a Lua script to ensure atomicity. The script first checks if the lock key exists. If not, it proceeds to set the lock. The data structure used is a hash, with the main key being the business key (which we need to design) and the sub-key being a UUID: thread ID. The initial lock value is 1.
For mutual exclusion, if thread 1 has already acquired the lock, thread 2 will also execute the same Lua script. It will check for the existence of the key and find that it exists (since both threads 1 and 2 have the same lock key). It will then check if the hash structure contains thread 2's ID. If not, it will return the remaining time of thread 1's lock and then use a while loop to acquire the lock.
For reentrant locks, the logic is the same as for mutual exclusion, but any thread can pass the check, and the value in the hash structure for that key is incremented by 1 using the incrby command.
The principle of releasing the lock is to call the unlock() method, which decrements the value in the hash structure for the holding thread. If the value is 0, the lock is deleted.
Redisson's implementation of distributed locks adds a watchdog mechanism to prevent the lock from being released prematurely if the task has not completed. This is essentially a background task thread that, after successfully acquiring the lock, adds the thread holding the lock to a map. It then checks every 10 seconds if the thread still holds the lock key (by iterating over the thread IDs in the map and querying Redis). If it does, it continuously extends the lock key's lifetime.
If the service crashes, the watchdog mechanism disappears, and the key's expiration time will not be extended, causing it to expire after 30 seconds, allowing other threads to acquire the lock.

Optimizing Distributed Locks

To reduce the triggering of distributed locks or optimize performance in concurrent scenarios, consider sending tokens with expiration times and using MQ to broadcast updates to the token, with the distributed lock serving as a fallback operation.

Handling Redis Failures

If Redis goes down while a Java thread holds a Redisson distributed lock, several issues may arise:
The lock may be lost, especially in a single-instance or master-slave architecture.
The lock may not be renewed if the watchdog mechanism fails.
The lock may be released if it expires before Redis restarts.
Solutions include enabling Redis persistence, setting reasonable lock expiration times, using high-availability architectures like Redis Sentinel or Redis Cluster, and implementing the Redlock algorithm across multiple Redis instances.

Designing Distributed Lock Keys

When using Redisson's lock, the key is a fixed business string plus a unique token.

Thread Pools and Multithreading

Thread Pool Execution Process

The execute() method's logic involves checking the number of threads against the core pool size, adding tasks to the queue if the core threads are busy, creating new non-core threads if the queue is full, and handling new tasks with a rejection policy if the pool is at capacity.

Core Parameters of Thread Pools

The constructor of a thread pool includes parameters like corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, and handler.

Rejection Policies of Thread Pools

Rejection policies include AbortPolicy, CallerRunsPolicy, DiscardPolicy, and DiscardOldestPolicy.

Queue Types for Thread Pools

Supported queue types include ArrayBlockingQueue, LinkedBlockingQueue, PriorityBlockingQueue, and DelayQueue.

Usage Scenarios for Thread Pools

Thread pools are used for quick responses and high throughput, such as parallel service calls or processing message queues.

Optimization and Considerations for Thread Pools

Avoid using Executors factory methods, handle task exceptions properly, and monitor thread pool performance to adjust parameters and prevent overload.

Lock Mechanisms in Thread Pools

Internally, thread pools use locks like mainLock to protect shared resources and Worker thread locks to manage thread interruption status.

Extending and Customizing Thread Pools

You can implement a ThreadFactory interface to customize thread creation and define custom rejection policies based on business needs.

Pre-creation of Core Threads

By default, core threads are created on demand when tasks are submitted. However, you can pre-create core threads using methods like prestartCoreThread() or prestartAllCoreThreads().

Idle Core Thread Destruction

Core threads remain alive until the pool is shut down. If allowCoreThreadTimeOut is set to true, idle core threads may be destroyed after keepAliveTime.

State of Core and Non-Core Threads When Idle

Core threads wait for new tasks, while non-core threads wait for a certain time (keepAliveTime) and are destroyed if no new tasks arrive.

Logging and Measuring Task Execution Time

You can wrap tasks with FutureTask to add logging logic or override ThreadPoolExecutor's beforeExecute and afterExecute methods to perform actions before and after task execution.

Dynamic Core Pool Size Adjustment

The core pool size can be dynamically adjusted using the setCorePoolSize(int newCorePoolSize) method. If the new size is larger, new core threads will be created; if smaller, excess threads may be terminated.

Behavior When corePoolSize Is Increased

If the corePoolSize is increased and there are tasks in the queue, new core threads will be created to handle the tasks.

Handling Idle Threads with keepAliveTime

The keepAliveTime is not managed by a task but by the Worker thread's runWorker method, which exits the thread if no tasks are received within the keepAliveTime.

Use of NANOSECONDS in workQueue.poll

The workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) method uses NANOSECONDS for precision. Although the time unit can be specified when creating the thread pool, it is internally converted to nanoseconds for consistent time management.

Key Concepts in Operating Systems

Ryan Zhi — Sat, 01 Feb 2025 16:06:11 +0000

Operating systems are the backbone of modern computing, managing resources and providing a seamless user experience. In this blog post, we'll delve into some of the most critical concepts in operating systems that every developer should understand. We'll cover processes and threads, virtual memory, I/O multiplexing, inter-process communication (IPC), process synchronization, and process scheduling. Let's dive in!

1. Processes vs. Threads

Processes
Definition: A process is the basic unit of resource allocation in an operating system. It has its own independent address space, global variables, and stack.
Characteristics:
Processes are independent of each other, meaning they don't interfere with one another.
Inter-process communication (IPC) is relatively complex and typically involves mechanisms like pipes, message queues, or shared memory.
Threads
Definition: A thread is the basic unit of CPU scheduling and usually resides within a process.
Characteristics:
Threads share resources within the same process, such as memory address space and global variables.
Communication between threads is simpler and can be achieved through shared memory and semaphores.

2. Virtual Memory

Virtual memory is a crucial memory management mechanism provided by operating systems. It allows programs to behave as if they have access to a large, contiguous memory space, even though physical memory is limited. Virtual memory achieves this by dynamically allocating memory between physical RAM and disk storage.
How Virtual Memory Works
Virtual memory uses the Memory Management Unit (MMU) to map virtual addresses to physical addresses. The address space is divided into fixed-size pages, and physical memory is divided into corresponding page frames. The mapping between virtual and physical addresses is managed by the operating system's page tables.
Address Space Layout
The virtual memory address space typically consists of:
Text Segment: Stores the program code.
Data Segment: Stores global and static variables and initialized data.
Heap: Used for dynamic memory allocation (e.g., via malloc or new).
Stack: Stores local variables and function call parameters, supporting recursion.
Memory-Mapped Area: Used for loading shared libraries (e.g., .so files) or mapping files.
Paging and Page Tables
Virtual memory uses pages and page frames to map virtual addresses to physical addresses. The virtual address space is divided into pages (e.g., 4KB each), and the physical memory is divided into page frames of the same size. The page table keeps track of the mapping between virtual and physical addresses.
Demand Paging and Page Replacement
Demand Paging: The operating system loads pages into memory on-demand rather than loading the entire program at startup. When a program accesses a page not in memory, a page fault occurs, and the OS loads the page from disk.
Page Replacement Algorithms: When physical memory is insufficient, the OS must swap out some pages to disk. Common algorithms include:
Least Recently Used (LRU): Replaces the least recently used page.
First-In-First-Out (FIFO): Replaces the oldest page in memory.
Optimal: Replaces the page that will not be used in the future (theoretical and impractical).
Advantages of Virtual Memory
Isolation and Protection: Each process has its own virtual address space, preventing interference between processes. The OS can also set permissions (read-only, writable, etc.) to protect memory regions.
Scalability: Programs can use a larger address space than the physical memory available. Modern 64-bit systems can theoretically access TBs of virtual memory.
Sharing and Dynamic Linking: Multiple processes can share the same library files, reducing memory usage.
Flexible Memory Management: The OS can dynamically allocate and swap memory, allowing programs to behave as if they have continuous memory.
Disadvantages of Virtual Memory
Performance Overhead: Address translation and page faults can be costly, especially when loading data from disk.
High Hardware Requirements: Virtual memory requires hardware support, such as an MMU, which is not available on some older or embedded systems.
Applications of Virtual Memory
Virtual memory is essential in modern operating systems (Windows, Linux, macOS) and is crucial for multitasking, supporting large-scale applications, and efficient memory management.

3. I/O Multiplexing

I/O multiplexing is a technique that allows a single thread or process to handle multiple I/O operations simultaneously. It is particularly useful in high-concurrency systems, enabling efficient resource utilization and reducing CPU idle time.
Why I/O Multiplexing?
Traditional I/O operations are blocking, meaning the program waits for the I/O to complete before continuing. This is inefficient for applications like web servers or databases that handle many concurrent connections. I/O multiplexing allows a single thread to monitor multiple I/O channels and handle them when they become ready.
How I/O Multiplexing Works
The basic idea is that a single process or thread uses system calls to monitor multiple I/O channels (e.g., file descriptors). When an I/O channel is ready, the OS notifies the application, which then processes the I/O operation.
Implementations of I/O Multiplexing
Select:
Mechanism: Select monitors multiple file descriptors by placing them in a set. It blocks until one or more descriptors are ready for I/O.
Pros: Cross-platform support (Linux, Windows).
Cons: Limited to a small number of file descriptors (typically 1024) and can be inefficient with large numbers of descriptors.
Poll:
Mechanism: Similar to select but uses an array of file descriptors, allowing it to handle more descriptors.
Pros: Supports more file descriptors.
Cons: Still inefficient with very large numbers of descriptors.
Epoll (Linux-specific):
Mechanism: Epoll is an event-driven mechanism that uses a kernel-maintained event list. It notifies the application only when a file descriptor is ready, making it highly efficient.
Pros: Highly scalable and suitable for high-concurrency applications like web servers.
Cons: Limited to Linux.
Pros and Cons of I/O Multiplexing
Pros:
Reduces the number of threads or processes, minimizing creation and destruction overhead.
Efficient resource utilization and support for high concurrency.
Cons:
Complex programming model, requiring careful management of file descriptors and event callbacks.
Potential performance bottlenecks in extreme cases.
Blocking nature of underlying system calls like select and poll.
Summary
I/O multiplexing is a powerful technique for handling high-concurrency applications. While select and poll are suitable for smaller-scale applications, epoll is the go-to choice for large-scale, high-performance systems.

4. Inter-Process Communication (IPC)

IPC is the mechanism by which different processes exchange data. Common IPC methods include:
Pipes: Allow communication between parent and child processes, with unidirectional data flow.
Named Pipes: Similar to pipes but have a name in the file system, enabling communication between unrelated processes.
Message Queues: Allow multiple processes to send and receive messages in a FIFO order.
Shared Memory: Multiple processes can map to the same physical memory region for direct data sharing.
Semaphores: Used for synchronizing access to shared resources.

5. Process Synchronization

Process synchronization ensures that multiple processes access shared resources without conflicts. Common synchronization mechanisms include:
Mutexes: Ensure exclusive access to a shared resource by one process at a time.
Semaphores: Control access to shared resources using counters.
Read-Write Locks: Allow multiple readers but exclusive access for writers.
Condition Variables: Allow processes to wait for certain conditions to be met, often used with mutexes.

6. Process Scheduling

Process scheduling is a core function of operating systems, managing how multiple processes share the CPU. The goal is to allocate CPU time fairly, maximize system throughput, and minimize response times.
Process States
New: The process is just created and not yet scheduled.
Ready: The process is loaded into memory and waiting for CPU time.
Running: The process is currently executing on the CPU.
Blocked: The process is waiting for an event (e.g., I/O completion) and cannot execute.
Terminated: The process has completed execution or been terminated.
Scheduling Queues
Ready Queue: Contains all ready-to-run processes.
Blocked Queue: Contains processes waiting for events.
Scheduling Algorithms
First Come, First Served (FCFS):
Mechanism: Processes are executed in the order they arrive.
Pros: Simple to implement.
Cons: Poor fairness and can lead to long waiting times for short jobs.
Shortest Job First (SJF):
Mechanism: The shortest job is executed first.
Pros: Minimizes average waiting time.
Cons: Requires knowing job lengths in advance and can cause starvation for long jobs.
Round Robin (RR):
Mechanism: Each process gets a fixed time slice, and the CPU is switched to the next process when the time slice expires.
Pros: Fairness and good response time for interactive systems.
Cons: Performance can degrade with improper time slice settings.
Priority Scheduling:
Mechanism: Processes with higher priority are executed first.
Pros: Suitable for real-time systems.
Cons: Can cause starvation for low-priority processes.
Multilevel Feedback Queue:
Mechanism: Processes are assigned to different queues with varying priorities and scheduling algorithms.
Pros: High flexibility and adaptability.
Cons: Complex implementation.
Performance Metrics
Average Waiting Time: The average time a process spends in the ready queue.
Average Turnaround Time: The total time from process submission to completion.
CPU Utilization: The percentage of time the CPU is busy.
Throughput: The number of processes completed per unit time.
Response Time: The time from user request to system response.
Summary
Process scheduling is a critical component of operating systems, impacting performance, fairness, and user experience. Choosing the right scheduling algorithm depends on system requirements, process types, and user needs. Understanding these concepts is essential for developers working on system-level applications or performance optimization.

Computer Networking: Key Interview Questions and Learning Points

Ryan Zhi — Wed, 29 Jan 2025 01:23:06 +0000

Understanding the TCP/IP Model and Common Protocols

The TCP/IP model, a foundational concept for internet communication, consists of four layers, each serving a distinct purpose in the transmission of data over the network. Let’s break down the protocols associated with each layer and explore their functionalities.

Application Layer Protocols

HTTP (Hypertext Transfer Protocol): The standard protocol used for transferring web pages and resources over the internet.
SMTP (Simple Mail Transfer Protocol): Used for sending emails between servers.
POP3/IMAP (Post Office Protocol/Internet Message Access Protocol): Protocols for retrieving emails from a server.
FTP (File Transfer Protocol): Used for transferring files between client and server.
Telnet: A protocol for remote command-line access.
SSH (Secure Shell Protocol): A secure version of Telnet, providing encrypted communication.
RTP (Real-Time Transport Protocol): Used for real-time communication, such as audio and video streaming.
DNS (Domain Name System): A system that translates domain names into IP addresses.

Transport Layer Protocols

TCP (Transmission Control Protocol):
- Provides reliable data transmission by ensuring data packets are delivered in the correct order.
- Features like flow control, congestion control, and error detection make TCP reliable.
- TCP Segments: Data is segmented, numbered, and acknowledged, ensuring data integrity.
UDP (User Datagram Protocol):
- Unlike TCP, UDP is connectionless, offering faster transmission at the cost of reliability.
- RDT (Reliable Data Transfer) protocols can be built on top of UDP to handle reliability.

Network Layer Protocols

IP (Internet Protocol): The core protocol responsible for addressing and routing data packets across networks.
ARP (Address Resolution Protocol): Resolves IP addresses to MAC addresses in local networks.
ICMP (Internet Control Message Protocol): Used for sending control messages like error reporting (e.g., "ping" command).
NAT (Network Address Translation): Translates private IP addresses into public IP addresses and vice versa.
OSPF (Open Shortest Path First): A link-state routing protocol used in large enterprise networks.
RIP (Routing Information Protocol): A distance-vector routing protocol, often used in smaller networks.
BGP (Border Gateway Protocol): Used for routing data between different networks, particularly in large-scale networks like the internet.

Link Layer Protocols

Error Detection: Protocols ensure that data received is error-free, typically using checksums or CRCs.
Multiplexing: Technologies that enable multiple communications to share a single transmission medium.
CSMA/CD (Carrier Sense Multiple Access with Collision Detection): A protocol used in Ethernet networks to handle data collisions.
MAC (Media Access Control): Ensures that data is properly addressed and delivered on a physical network.
Ethernet: The most common local area network (LAN) technology.

HTTP Protocols Breakdown

Request and Response Messages

Request Message: Contains a request line (method, URL, HTTP version), headers (additional information like Host, User-Agent), and an optional body (data for methods like POST).
Response Message: Contains a status line (HTTP version, status code, status message), headers, and an optional body (data like HTML or JSON content).

Common HTTP Status Codes:

2xx: Successful requests (e.g., 200 OK).
3xx: Redirection (e.g., 301 Moved Permanently).
4xx: Client error (e.g., 404 Not Found).
5xx: Server error (e.g., 500 Internal Server Error).

HTTP Methods:

GET: Retrieves data from the server.
POST: Sends data to the server.
PUT: Updates existing data.
DELETE: Removes data.
HEAD: Fetches headers without the body.

GET vs POST:

GET is used to fetch resources, typically data retrieval.
POST is used to send data to the server, typically for creating or updating resources.

HTTP Connections:

Short Connection: Each request/response cycle requires a new TCP connection.
Long Connection: A persistent TCP connection is used to send multiple requests and responses, reducing overhead (enabled by Keep-Alive).

HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1:
- Uses long connections and pipelining for performance improvement but faces head-of-line blocking.
HTTP/2:
- Header Compression (HPACK) reduces redundancy.
- Binary Protocol improves parsing efficiency.
- Multiplexing enables parallel data transfer to avoid blocking.
HTTP/3:
- Built on QUIC, uses UDP for faster connection establishment.
- Eliminates head-of-line blocking and allows connection migration for seamless transitions between networks.

HTTPS (Secure HTTP)

Port: HTTP uses port 80, while HTTPS uses port 443.
Encryption: HTTPS uses SSL/TLS to encrypt data, ensuring secure communication between client and server.
Authentication: Requires a digital certificate from a trusted Certificate Authority (CA).

TCP Overview

Why TCP Requires Three-Way Handshake:

Prevent Duplicate Connections: Ensures old or duplicate connections don't interfere.
Synchronizes Sequence Numbers: Both ends agree on the initial sequence numbers for reliable communication.
Resource Efficiency: Prevents wastage of resources by establishing a connection only when necessary.

TCP’s Reliability:

Sequence Numbers: Each byte of data has a unique sequence number to ensure data is in the correct order.
Acknowledgments: The receiver sends back an acknowledgment to the sender confirming data receipt.
Timeouts and Retransmissions: Ensures reliability by resending data if acknowledgment isn’t received.
Flow Control: Prevents congestion by regulating the data rate based on receiver’s capacity.
Congestion Control: Reduces transmission rate if network congestion is detected.

TCP vs UDP:

TCP: Reliable, connection-oriented, guarantees delivery, in-order delivery, and error-checking.
UDP: Faster, connectionless, no guarantees, better for real-time applications.

DNS (Domain Name System)

DNS translates human-readable domain names into IP addresses. It’s a distributed system that enables clients to access resources using domain names, such as "www.example.com", instead of having to remember numeric IP addresses.

DNS Resolution Process:

Client queries local DNS for the IP address of a domain.
If not cached, the local DNS queries the root DNS server.
The root DNS directs to the TLD server (e.g., for .com domains).
The TLD server directs to the authoritative DNS server for the domain.
The authoritative DNS responds with the IP address.
The local DNS returns the IP to the client.

Conclusion

TCP/IP protocols are integral to how the internet operates, with each layer providing distinct services and ensuring that data is transmitted reliably, securely, and efficiently. Understanding these protocols is key for building, maintaining, and troubleshooting network applications.

Let me know if you'd like to dive deeper into any of these topics!

Networking #TCPIP #WebProtocols #HTTP #DNS #TCP #UDP #HTTP2 #HTTP3 #Security #TechPost

Learning Virtual Threads in Java

Ryan Zhi — Mon, 27 Jan 2025 13:20:47 +0000

What are Virtual Threads?

Virtual threads, introduced in Java 19 and officially released in Java 21 (September 2023), are lightweight threads that are managed by the JVM, not the operating system. They are similar to goroutines in Go.

Why Were Virtual Threads Introduced?

The main issue that virtual threads solve is improving CPU utilization for I/O-bound tasks. Traditional multi-threading in Java can lead to inefficient CPU usage when a thread is waiting for I/O operations, such as network communication or file reading. For example, if a thread is waiting for data from the network or a disk, it blocks and doesn't do anything else, causing idle CPU time.

Virtual threads address this by allowing threads to "yield" and do other work when blocked on I/O, releasing the CPU and allowing other tasks to execute. Once the I/O operation is complete, the virtual thread resumes. This greatly increases CPU utilization because the thread doesn't sit idle while waiting for I/O operations to complete.

However, virtual threads don't increase the actual number of available CPU threads. Instead, they improve the efficiency of the threads by allowing them to be used more effectively. For CPU-intensive tasks like mathematical calculations, virtual threads behave similarly to traditional threads. But if your workload involves significant I/O blocking, virtual threads can provide a notable performance boost.

How Do Virtual Threads Work?

Virtual threads are mapped to platform threads, which can be understood as platform threads being like electrical sockets that only allow one device to be plugged in. Virtual threads are like power strips, allowing multiple threads to share the same platform thread without blocking it when inactive. This metaphor, while not perfectly accurate, illustrates the idea of multiple virtual threads being managed on a single platform thread.

Key Concepts:

Scheduling Queue: Virtual threads are managed and scheduled by the JVM using a scheduling queue, which tracks all the suspended virtual threads. The queue ensures that threads are resumed in the order they were suspended.
Scheduler: The scheduler manages platform threads and assigns virtual threads to them when they are available. The default scheduler in Java uses a FIFO-based ForkJoinPool, which uses a "work-stealing" algorithm to maximize throughput.

Execution Flow:

Creation: A virtual thread is created and placed in the scheduling queue.
Mounting: The JVM's scheduler selects a platform thread and "mounts" a virtual thread onto it, allowing it to run.
Execution: The virtual thread runs its task until it encounters a blocking operation.
Unmounting: If the thread becomes blocked, it is "unmounted" from the platform thread, which is then free to execute other tasks.
Suspension: The blocked thread is suspended by the JVM and placed back into the scheduling queue.
Resumption: Once the blocking condition is cleared (e.g., I/O completes), the thread is resumed and mounted back onto a platform thread.
Completion: The virtual thread continues execution until it completes, at which point it is garbage collected when there are no more references to it.

Continuations: The Core of Virtual Threads

The concept of continuations is crucial for virtual threads. A continuation is a data structure that holds the state of a task and allows it to be paused and resumed. This enables the JVM to suspend and resume tasks on virtual threads.

When a virtual thread needs to block (e.g., during I/O operations), the JVM uses a continuation to suspend the thread.
When the I/O completes, the JVM uses the continuation to resume the thread from where it was suspended.

The platform thread that is executing a virtual thread is also called the carrier thread. The JVM schedules virtual threads onto carrier threads in a way that allows for efficient resource usage. When a virtual thread is mounted onto a carrier thread, the thread's stack data (in the form of continuation frames) is copied into the carrier thread's stack.

Mounting and Unmounting Virtual Threads

Mounting: The process of assigning a virtual thread to a carrier platform thread. This involves copying the virtual thread's continuation stack frames to the carrier thread's stack, effectively transferring the virtual thread's execution to the platform thread.
Unmounting: When a virtual thread becomes blocked, it is "unmounted" from the platform thread, and its continuation data is often left on the heap (in memory) to be resumed later.

Key Takeaways:

Virtual threads provide lightweight task management within the JVM, enabling applications to handle large numbers of concurrent I/O-bound tasks efficiently.
They allow a single platform thread to carry out the work of many virtual threads, reducing the overhead typically associated with creating and managing threads.
Virtual threads are ideal for I/O-bound workloads (e.g., network requests, file I/O) but may not be as beneficial for CPU-bound tasks due to the limited number of platform threads available.
Continuations handle the suspension and resumption of tasks, providing a way for the JVM to manage the execution of virtual threads across platform threads.

Use Cases:

I/O-Intensive Tasks: Virtual threads are perfect for handling a large number of I/O operations, such as handling HTTP requests or processing file operations.
Concurrency in High-Load Applications: Virtual threads can help manage thousands or even millions of concurrent tasks without the memory and CPU overhead of traditional threads.
Async Programming: Virtual threads can simplify asynchronous programming by making it look and behave more like traditional synchronous code, improving readability and reducing complexity.

Summary

Virtual threads represent a powerful tool in Java for optimizing resource usage in highly concurrent, I/O-heavy applications. By efficiently handling blocking I/O operations and allowing threads to be more lightweight, they make it easier to scale applications while avoiding the overhead of managing a massive number of platform threads. However, virtual threads are not a silver bullet for every kind of task—particularly for CPU-bound tasks, where traditional threading models still hold an advantage.

Understanding Thread Pools and Thread Management in Java

Ryan Zhi — Sun, 26 Jan 2025 15:19:27 +0000

Sure! Here's your content rewritten into a North American programmer-style post, with an added title:

Understanding Thread Pools and Thread Management in Java

Thread pools are an essential tool in Java programming, providing a way to manage and reuse threads efficiently, which helps improve performance by avoiding the overhead of constantly creating and destroying threads. Let’s break down the key concepts and working principles of thread pools, thread management, and related mechanisms in Java.

Thread Pool Basics

A thread pool is a collection of threads that are pre-created and managed for executing tasks, reducing the cost of creating new threads frequently. The core elements of thread pools include:

Core Pool Size: The minimum number of threads that are always running.
Maximum Pool Size: The maximum number of threads the pool can accommodate.
Keep-Alive Time: The time a thread is allowed to be idle before it is terminated.
Work Queue: A queue that holds tasks before they are executed.
Rejection Policy: What happens when tasks are submitted but the pool is full.

Here’s a basic flow of how a thread pool operates:

Thread Creation: Threads are created only when tasks are submitted (though you can pre-create them using prestartAllCoreThreads).
Task Queuing: If the core threads are busy, tasks are added to the work queue instead of creating new threads.
Expanding Threads: If the work queue is full, the pool will create new threads (up to the maximum pool size).
Rejection Handling: When both the work queue and pool size limits are reached, a rejection policy kicks in.
Thread Termination: Threads that are idle longer than the keep-alive time will be terminated unless they are core threads. Core threads won’t be terminated unless allowCoreThreadTimeOut is set to true.

Non-Core Threads and Their Reclamation

Non-core threads are typically added to handle burst loads. When idle, they are reclaimed if they don’t get new tasks after a certain period. This reclamation happens via the Poll method in the work queue. When threads don't find tasks, the method returns null, which leads to their termination.

Can Core Threads Be Reclaimed?

By default, core threads are not reclaimed. However, if you set allowCoreThreadTimeOut = true, they will be reclaimed once they exceed the keep-alive time.

Thread Blocking and Idle States

Blocking States: Threads enter a blocking state when waiting on synchronized methods or blocking operations like sleep(), wait(), or join().
Core Threads in Idle State: Core threads typically block on the take() method of the work queue when waiting for tasks. Non-core threads, on the other hand, use poll() and will be terminated if idle for too long.

Stopping Threads

Threads can be interrupted or stopped in various ways:

interrupt(): Marks a thread for interruption. The thread must cooperate by checking its interrupted status and handling InterruptedException to stop gracefully.
isInterrupted(): Checks if a thread has been interrupted.
stop(): This method has been deprecated as it can lead to inconsistent thread state.
Thread.interrupted(): Clears the interrupt flag when called.

Virtual Threads: A New Era in Concurrency

With JDK 19 (Preview) and officially in JDK 21, Java introduced Virtual Threads, which are lightweight threads managed by the JVM. Unlike traditional OS-level threads, virtual threads don’t map directly to native OS threads, reducing the performance overhead associated with context switching.

Virtual Thread vs. Traditional Thread

Traditional Threads: Each maps directly to an OS-level thread.
Virtual Threads: Managed by the JVM and are more lightweight, allowing large numbers to be created without heavy resource consumption.

Virtual threads are ideal for I/O-bound tasks, where threads spend a lot of time waiting for external operations (e.g., network calls, database queries). They’re less suitable for CPU-bound tasks due to their dependency on physical threads for execution.

Benefits of Virtual Threads

Efficiency for I/O-bound Tasks: Virtual threads can handle a large number of concurrent I/O operations with minimal overhead.
Lightweight: Much faster to create and switch between than traditional threads.
Automatic Scheduling: The JVM can manage their scheduling, reducing the need for manual thread pool management.

However, for CPU-bound tasks, the use of virtual threads might result in resource contention because virtual threads share physical threads, which are limited by CPU cores.

Why ThreadLocal Uses Weak References

In Java, ThreadLocal is used for storing data that is specific to the current thread. To avoid memory leaks when using thread pools, ThreadLocal uses weak references for its keys. This ensures that when a thread ends, the associated data can be garbage collected. Without weak references, thread-local data would remain in memory, even after a thread has finished execution, which could lead to memory leaks.

To prevent this, ThreadLocal automatically removes references when the thread ends, but it’s still good practice to call remove() manually to ensure resources are cleared promptly.

In Conclusion

Thread management is a critical aspect of writing efficient concurrent programs in Java. Understanding thread pools, virtual threads, and related mechanisms like ThreadLocal is essential for writing scalable, high-performance applications. Virtual threads open new possibilities, especially for handling large numbers of I/O-bound tasks without overwhelming system resources.

As always, choosing the right concurrency model (traditional thread pools vs virtual threads) depends on the specific use case: I/O-bound tasks are perfect for virtual threads, but CPU-bound tasks are better off using traditional threads to avoid context-switching overhead.

In-Depth Study of ZGC (Z Garbage Collector)

Ryan Zhi — Sat, 25 Jan 2025 14:42:45 +0000

Java 11 introduced the Epsilon garbage collector, which is used in scenarios where no garbage collection is needed. It controls memory allocation but does not perform any garbage collection tasks. Once the heap memory is exhausted, the JVM shuts down directly. Additionally, ZGC (Z Garbage Collector) was introduced as an experimental garbage collector in Java 11, and Shenandoah GC was introduced in Java 12 as an experimental version, which became production-ready by Java 15. Java 17 marked the official LTS release with these enhancements.

1. What is ZGC?

ZGC (Z Garbage Collector) is a low-latency garbage collector in Java, specifically designed to handle large heap sizes, ranging from hundreds of MBs to 16 TB. It achieves this by using concurrent marking and concurrent relocation techniques to keep garbage collection pauses extremely low, typically under 1 millisecond, regardless of the heap size. ZGC incorporates several innovative technologies like colored pointers, load barriers, and memory multi-mapping to manage memory efficiently and perform garbage collection.

2. The Three-Color Marking Algorithm

The Three-Color Marking algorithm is used in garbage collection to track live objects in memory. It categorizes objects into three colors:

White: The initial state, representing unvisited objects. These objects will be collected after marking is complete.
Gray: Objects that have been visited but whose references have not yet been visited. Gray objects are in a transitional state during the marking process.
Black: Objects that and all their referenced objects have been visited and marked as live.

3. ZGC Use Cases

ZGC is particularly useful in the following scenarios:

Large Memory Applications: Such as real-time data analytics, high-performance servers, and online transaction systems, which need to handle TB-sized heap memory.
Low Latency Requirements: Ideal for applications that require real-time responses, like high-frequency trading systems and online games. ZGC’s low pause times (typically less than 1ms) meet these needs.
Cloud Computing Platforms: ZGC’s scalability and low-latency characteristics make it well-suited for managing shared resources in multi-tenant cloud environments.

4. How ZGC Works

ZGC’s garbage collection process includes several phases:

Initial Mark: A quick marking phase where all the live roots are identified.
Concurrent Marking: Concurrently marks live objects in the heap.
Remark: Another short phase where the system reconciles any discrepancies.
Concurrent Relocation: Moves the live objects and compacts the heap while the application continues to run.

5. ZGC's Current Challenges

Java has introduced a generational ZGC in recent updates. ZGC operates differently from traditional garbage collectors like CMS or G1 in that it does not have the concept of generations but uses regions similar to G1. ZGC's regions come in three sizes:

Small Region: 2MB in size, holds objects smaller than 256KB.
Medium Region: 32MB in size, for objects between 256KB and 4MB.
Large Region: A flexible size (must be a multiple of 2MB), used for large objects (4MB+). These regions are not reallocated because copying large objects is very expensive.

6. ZGC's Pause Time Characteristics

Unlike CMS, where the entire garbage collection phase is Stop-The-World (STW), ZGC is designed to be almost entirely concurrent. ZGC has three STW phases: Initial Mark, Remark, and Initial Relocation. Most of the work is done concurrently, and pauses are not dependent on the heap size or the number of active objects. This ensures that ZGC achieves its goal of minimizing pauses.

7. ZGC Configuration Options

-Xms -Xmx: Set both the minimum and maximum heap sizes to 10GB.
-XX:ReservedCodeCacheSize: Set the size of the code cache used for JIT-compiled code.
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC: Enables ZGC in the JVM.
-XX:ConcGCThreads: Specifies the number of threads for concurrent garbage collection. By default, it's 12.5% of the number of CPU cores.
-XX:ParallelGCThreads: Defines the number of threads for STW phases. Default is 60% of the CPU cores.
-XX:ZCollectionInterval: The minimum time interval between ZGC collections (in seconds).
-XX:ZAllocationSpikeTolerance: Adjusts when ZGC triggers based on allocation spikes.
-XX:+UnlockDiagnosticVMOptions -XX:-ZProactive: Controls proactive garbage collection behavior.
-Xlog: Configures logging for garbage collection events.

8. ZGC Trigger Mechanisms

ZGC’s GC trigger mechanism differs significantly from CMS and G1. One of ZGC's core features is concurrency, and during the GC process, new objects may be created. The challenge lies in ensuring that the heap does not fill up before GC completes, as this could cause threads to block.

Some key ZGC triggering mechanisms are:

Blocking Memory Allocation Requests: When the heap fills up faster than GC can handle, threads may be blocked. The keyword in logs for this is "Allocation Stall."
Adaptive Algorithm Based on Allocation Rate: ZGC dynamically calculates when to trigger GC based on the recent allocation rate and GC times. This method helps avoid triggering too early and causing unnecessary pauses. The log keyword for this is "Allocation Rate."
Fixed Time Intervals: ZGC can also be triggered based on fixed intervals, which is useful for burst traffic scenarios. The log keyword for this is "Timer."
Proactive GC: When ZGC calculates that GC should happen earlier than normal, this can be triggered proactively. This can be controlled with the -ZProactive flag. Logs will show the keyword "Proactive."
Warmup Phase: This occurs during service startup and is usually not of concern. Logs will show the keyword "Warmup."
External Triggering: Explicit calls to System.gc() can also trigger GC, which is reflected in the logs as "System.gc()."

9. Key Innovations in ZGC

ZGC uses a combination of colored pointers, load barriers, and memory multi-mapping to achieve low-latency garbage collection.

Colored Pointers: ZGC uses the high-order bits of a 64-bit pointer to store GC state information. These bits include flags like Marked0, Marked1, and Remapped, which indicate whether an object has been marked as live, whether it's been moved, or whether it's ready for finalization.
Load Barriers: ZGC ensures memory consistency during object access by using load barriers. These barriers check the object's pointer color and ensure that the pointer is updated to the correct memory location if the object has been moved during GC.
Memory Multi-Mapping: ZGC maps the same physical memory to multiple virtual addresses, each representing a different GC state (e.g., Marked0, Marked1, Remapped). This allows ZGC to efficiently switch between views of memory without actually moving data, improving flexibility and efficiency.

Conclusion

ZGC is a revolutionary step forward in Java's garbage collection strategy, particularly for applications with large heaps and low-latency requirements. By using advanced techniques like colored pointers, load barriers, and memory multi-mapping, it can achieve low pause times even with large-scale memory management. With its concurrent phases and advanced triggering mechanisms, ZGC is well-suited for cloud environments, real-time systems, and applications that require high throughput and low latency.

Learning and Reflections on Java 8 Garbage Collectors

Ryan Zhi — Fri, 24 Jan 2025 14:03:47 +0000

Why Companies Still Use Java 8

Recently, I've been asking many friends about the Java versions they use in their projects. I found that a significant number of projects still run on Java 8, while some have moved to higher versions like Java 17 or Java 21. In these projects, choosing and tuning the garbage collector (GC) is a crucial part of optimizing application performance.
Many senior colleagues told me that around 80% of companies still use JDK 8. This is mainly because they choose between CMS and G1 based on memory requirements. In the current tech landscape, few new internet companies are emerging, and most prefer to stick with what they know to avoid increasing team workload and potential pitfalls.

From a Management Perspective

Optimization Benefits
Upgrading to newer Java versions (like Java 17 or Java 21) might bring performance improvements and support for new features. However, it's essential to weigh these benefits against the effort and risks involved in the upgrade process.
Workload and Risk
Upgrading requires adapting and testing existing code, which could introduce new issues. Management needs to assess whether the upgrade is necessary and prepare a technical feasibility analysis to report to higher-ups.

From a Developer's Perspective

Increased Workload
Upgrading means retesting all modules, which is time-consuming and labor-intensive. This can lead to conflicts between developers and management regarding workload and scheduling.
Technical Risks
Newer versions may have undiscovered compatibility or performance issues, adding uncertainty to the project.

Java 8 Garbage Collectors

Serial Garbage Collector (Serial GC)

Characteristics
Uses a single thread for garbage collection, causing all user threads to pause (Stop-The-World, STW) during GC.
Simple and efficient with no overhead from thread interactions.
Best for single-threaded environments or small applications.

Use Cases

According to the official documentation, if your application has a small dataset (up to around 100 MB) or runs on a single processor with no pause time requirements, you can use -XX:+UseSerialGC to select the Serial Collector.
Suitable for single-core CPU environments or resource-constrained scenarios.
Applications with low latency requirements and small datasets.

Parallel Garbage Collector (Parallel GC)

Characteristics

Uses multiple threads for garbage collection to reduce pause times.
Focuses on high throughput.

Use Cases

If peak application performance is the top priority and there are no pause time requirements or pauses of 1 second or longer are acceptable, use -XX:+UseParallelGC to select the Parallel Collector.
Suitable for multi-core processor environments.
Batch processing or big data processing scenarios.

CMS Garbage Collector (Concurrent Mark-Sweep GC)

Characteristics

Aims to minimize pause times using a concurrent mark-sweep algorithm.
The process includes initial mark, concurrent mark, remark, and concurrent sweep stages.
Best for applications sensitive to response times.
The CMS collector only works on the old generation and is based on the mark-sweep algorithm. Its operation consists of four steps:
Initial Mark (CMS initial mark)
Marks objects directly reachable from GC Roots. This stage is very quick and requires a brief STW pause.
Concurrent Mark (CMS concurrent mark)
Traces objects from GC Roots to mark live objects. This stage is time-consuming but runs concurrently with the application.
Remark (CMS remark)
Fixes any changes in object markings caused by the application's activity during the concurrent mark stage. This stage is slightly longer than the initial mark but still much shorter than the concurrent mark.
Concurrent Sweep (CMS concurrent sweep)
Clears the marked regions. This stage runs concurrently with the application.

Use Cases

If response time is more critical than overall throughput and GC pauses need to be kept under 1 second, consider using -XX:+UseConcMarkSweepGC or -XX:+UseG1GC.
Suitable for web applications, online transaction systems, and other latency-sensitive scenarios.
Large memory applications, but be aware of memory fragmentation issues. This can be mitigated by triggering CMS more frequently followed by a compacting collection.

G1 Garbage Collector (Garbage-First GC)

Characteristics

Divides the heap into regions and prioritizes garbage collection in regions with the most garbage.
Provides predictable pause times and reduces memory fragmentation.
Best for large memory and multi-core environments.
The G1 collection process is as follows:
Initial Marking (Initial Marking)
Marks objects directly reachable from GC Roots and adjusts the TAMS (Next Top at Mark Start) value to ensure new objects are created in the correct regions. This stage requires a brief STW pause but is very quick.
Concurrent Marking (Concurrent Marking)
Traces objects from GC Roots to identify live objects. This stage is time-consuming but runs concurrently with the application.
Final Marking (Final Marking)
Fixes changes in object markings caused by the application's activity during the concurrent marking stage. This stage requires a brief STW pause but can be executed in parallel.
Live Data Counting and Evacuation (Evacuation)
Sorts regions by their garbage collection value and cost, then evacuates objects based on the desired GC pause time. This stage can run concurrently with the application, and pausing user threads can significantly improve collection efficiency.

Use Cases

If your application fits the following criteria, consider migrating from CMS or ParallelOld to G1 for better performance:
More than half of the heap is occupied by live data.
Object allocation or promotion rates vary significantly.
You want to eliminate long GC pauses (over 0.5–1 second).
In practice, applications with 8 GB or more memory generally use the G1 garbage collector. Smaller memory sizes can lead to frequent GC cycles, which degrade performance.
Suitable for large applications requiring low latency and high throughput.
Ideal for e-commerce platforms, game servers, and other performance-critical scenarios.

Conclusion

While newer Java versions offer exciting features and improvements, many companies still rely on Java 8 due to its stability and familiarity. Garbage collector tuning remains a critical aspect of optimizing Java applications, and understanding the strengths and weaknesses of each collector is essential for making informed decisions.

Java Concurrency Mastery: A Comprehensive Guide to AQS, Locks, and Concurrent Collection

Ryan Zhi — Thu, 23 Jan 2025 08:44:29 +0000

AbstractQueuedSynchronizer (AQS) AQS is the backbone of many concurrency utilities in Java. It's a framework for building locks and synchronizers. Key Features: State Management: AQS maintains a state variable that represents the synchronization state. This state can have different meanings depending on the implementation (e.g., lock count for ReentrantLock, read/write counts for ReentrantReadWriteLock). FIFO Queue: AQS uses a FIFO queue to manage threads that fail to acquire the lock. Each thread is wrapped in a Node and enqueued. Condition Support: AQS provides a ConditionObject that allows threads to wait for specific conditions to be met. Each condition maintains its own queue of waiting threads. Fairness: AQS supports both fair and non-fair implementations, affecting how threads acquire locks.
ReentrantLock A reentrant lock is a synchronization primitive that provides more flexibility than intrinsic locks (synchronized). Key Features: Reentrancy: A thread can acquire the lock multiple times, and the lock count is incremented each time. Fairness: Can be configured to be fair (threads acquire locks in FIFO order) or non-fair (threads may acquire locks out of order). Condition Support: Allows threads to wait for specific conditions using Condition objects. Interruptibility: Threads waiting to acquire the lock can be interrupted.
ReadWriteLock ReadWriteLock allows multiple readers to access a resource simultaneously while ensuring exclusive access for writers. Key Features: Shared Locks (Read Locks): Multiple threads can hold the read lock simultaneously. Exclusive Locks (Write Locks): Only one thread can hold the write lock at a time. Upgrade/Downgrade: Supports lock downgrade (write lock to read lock) but not upgrade (read lock to write lock). Fairness: Can be configured to be fair or non-fair.
LockSupport LockSupport is a utility class that provides basic thread blocking and unblocking mechanisms. Key Features: Blocking: Uses park() to block a thread. Unblocking: Uses unpark() to unblock a thread. Low-Level: Often used internally by other concurrency utilities but can also be used directly for custom synchronization.
Concurrent Collections Java provides several thread-safe collections optimized for concurrent access. ConcurrentHashMap High Concurrency: Uses a combination of segment locks and CAS operations to allow high concurrency. No Null Keys/Values: Does not allow null keys or values. ConcurrentLinkedQueue Lock-Free: Uses CAS operations for thread safety. Unbounded: No fixed capacity. CopyOnWriteArrayList Write-Heavy: Writes are expensive as they involve copying the entire array. Read-Heavy: Reads are extremely fast and lock-free. ConcurrentSkipListMap/ConcurrentSkipListSet Ordered: Maintains elements in sorted order. High Concurrency: Uses fine-grained locking.
Blocking Queues Blocking queues are thread-safe queues that support blocking operations. ArrayBlockingQueue Bounded: Fixed capacity. Fairness: Can be configured to be fair. LinkedBlockingQueue Unbounded: Can be configured with a capacity, but defaults to unbounded. Performance: Better performance than ArrayBlockingQueue. PriorityBlockingQueue Priority: Elements are ordered by priority. Unbounded: No fixed capacity. SynchronousQueue Direct Handoff: No storage; producer threads wait for consumer threads and vice versa. DelayQueue Delayed Access: Elements can only be accessed after a specified delay. LinkedTransferQueue Transfer: Supports direct handoff between producer and consumer threads.
Atomic Classes Atomic classes provide thread-safe operations on single variables. Key Features: CAS Operations: Use Compare-And-Swap (CAS) to ensure atomicity. No Locks: Avoids the overhead of traditional locks. Memory Barriers: Ensures visibility of changes across threads. Common Classes: AtomicInteger AtomicLong AtomicBoolean AtomicReference AtomicIntegerArray
Thread Pools Thread pools manage a pool of worker threads to execute tasks efficiently. Key Features: Core and Max Threads: Manages a core pool size and a maximum pool size. Work Queue: Tasks are queued if all core threads are busy. Rejected Execution: Handles tasks when the queue is full and the maximum pool size is reached. Idle Threads: Can be terminated if they remain idle for a specified duration. Common Executors: FixedThreadPool: Fixed number of threads. CachedThreadPool: Dynamically creates threads as needed. SingleThreadExecutor: Single-threaded executor. ScheduledThreadPool: Supports scheduled and periodic tasks.
Synchronization Utilities Java provides several utilities for synchronizing threads. CountDownLatch One-Time Use: Allows one or more threads to wait for a set of operations to complete. Count Down: Threads call countDown() to decrement the counter. Await: Threads call await() to wait until the counter reaches zero. CyclicBarrier Reusable: Allows multiple threads to wait at a barrier point. Barrier Action: Optional action to be executed when all threads reach the barrier. Reset: Can be reset for reuse. Semaphore Permits: Manages a set of permits that threads can acquire. Fairness: Can be configured to be fair or non-fair. Acquire/Release: Threads acquire permits to access resources and release them afterward.

A Deep Dive into Java’s Concurrency Framework (JUC)

Ryan Zhi — Wed, 22 Jan 2025 10:21:56 +0000

As developers, writing efficient and thread-safe concurrent code can be challenging, but Java provides a robust concurrency framework called Java Util Concurrent (JUC) to simplify this process. Whether you’re working on complex multithreaded systems or looking to optimize performance under high concurrency, JUC has you covered. Here's a breakdown of its major components:
🔐Locks
JUC’s lock mechanism goes beyond the synchronized keyword, offering greater flexibility and functionality:

ReentrantLock: A reentrant lock with enhanced features, like interruptible locks, fairness policies, and timeout-based locking.
ReentrantReadWriteLock: Separates read and write locks for better performance under read-heavy workloads. Multiple threads can acquire the read lock simultaneously, while the write lock ensures exclusive access.
StampedLock: Introduced in JDK 8, this offers a more advanced optimistic locking mechanism, enabling fine-grained control with modes like optimistic read, pessimistic read, and write locks.
LockSupport: A utility class for advanced thread blocking and waking mechanisms, often used to implement custom synchronization constructs.
Condition: Provides a finer-grained thread communication mechanism, enabling more flexible wait/notify patterns in combination with locks.
🛠 Concurrency Tools
These utility classes are designed for advanced thread coordination:

CountDownLatch: A synchronization aid that allows one or more threads to wait until a set of operations are completed. Ideal for tasks like waiting for multiple services to initialize.
CyclicBarrier: Allows a group of threads to synchronize at a common barrier point. Once all threads reach the barrier, they can proceed. What makes it unique? It’s reusable for multiple cycles.
Semaphore: A classic concurrency control tool that limits access to a resource pool by a specified number of threads. Perfect for managing limited connections or rate-limiting APIs.
⚛️ Atomic Classes
JUC offers a suite of atomic classes for lightweight, lock-free thread safety:

Examples include AtomicInteger, AtomicBoolean, and AtomicReference.
Backed by volatile and CAS (compare-and-swap) operations, they ensure visibility and atomicity without the overhead of explicit locks.
Use cases: shared counters, flags, or reference updates in highly concurrent environments.
🚀 Executors and Thread Pools
Thread management simplified! JUC provides Executor and ExecutorService interfaces for task execution:

ThreadPoolExecutor: A fully customizable thread pool, making it ideal for scalable and performant task execution.
ScheduledThreadPoolExecutor: Perfect for scheduling tasks with fixed delays or intervals.
ForkJoinPool: A pool optimized for divide-and-conquer algorithms, leveraging work-stealing for better CPU utilization.
CachedThreadPool: Dynamically creates threads as needed and reuses idle ones for short-lived tasks.
SingleThreadExecutor: Guarantees sequential execution of tasks using a single worker thread.
📦 Concurrent Collections
Thread-safe collections built for high-concurrency environments:

ConcurrentHashMap: A highly optimized, thread-safe hash map with fine-grained locking (bucket-level). It provides non-blocking reads and controlled writes.
CopyOnWriteArrayList: Perfect for scenarios with frequent reads but infrequent writes, as every modification creates a new copy of the list.
ConcurrentSkipListMap and ConcurrentSkipListSet: Sorted, thread-safe collections built on the skip list data structure for fast lookups and updates.
Final Thoughts
JUC is a powerful toolbox for building scalable, performant, and thread-safe applications in Java. Whether you’re optimizing resource access with locks, managing threads with executors, or leveraging atomic operations for lock-free concurrency, JUC equips you with the tools you need.

What’s your favorite part of the JUC framework? Let me know in the comments! 👇

Summary of Deploying Vortex GPGPU on K7 FPGA Development Board

Ryan Zhi — Wed, 22 Jan 2025 08:55:11 +0000

Project Background

Our team consists of four members, each with a specific role. I am responsible for overall project coordination, scheduling, hardware architecture design, system integration, and data flow management. I also support team members when they encounter difficulties and escalate issues to our technical lead, Mr. Geng, if necessary. One team member focuses on testing, another on driver development, and the third on IP core modularization.
The primary goal of this project is to lay the groundwork for future Compute-in-Memory (CIM) chips by implementing a minimal-cost RISC-V-based GPGPU on a K7 FPGA. The architecture consists of one core, one socket, and one cluster.

What is Compute-in-Memory (CIM)?

Compute-in-Memory is an architecture that integrates computing capabilities within memory units, enabling efficient 2D and 3D matrix operations (multiplication and addition). Its key advantages include:
Breaking the memory wall by reducing unnecessary data movement delays and power consumption.
Enhancing computational efficiency by orders of magnitude while reducing costs.
CIM is a non-von Neumann architecture that can deliver significantly higher performance (over 1000 TOPS) and efficiency (exceeding 10-100 TOPS/W) compared to existing ASIC chips.

Project Design and Background

Why Choose Vortex GPGPU Based on RISC-V?

Efficiency and Open Ecosystem: RISC-V's minimal instruction set is more efficient than ARM, resulting in smaller chip area and better performance. Vortex GPGPU is open-source, offering greater customization and innovation opportunities compared to closed ecosystems like NVIDIA CUDA and AMD ROCm.
Research and Innovation: The RISC-V ecosystem is still rapidly evolving, providing ample opportunities for academic and industrial innovation, especially in hardware optimization and algorithm acceleration.

Challenges and Solutions in Deploying Vortex GPGPU on K7

Hardware Architecture Differences:

Challenge: U280 (UltraScale+) vs. K7 (Kintex-7) architecture; limited logic resources and memory bandwidth on K7.
Solution: Modular design using Vivado Block Design, optimized pipeline depth, and reduced non-essential logic to fit K7's resources.

PCIe Interface and Driver Differences:

Challenge: U280 supports Xilinx Runtime (XRT) and HBM, while K7 requires custom Linux drivers and XDMA IP.
Solution: Developed a Generic Virtual Interface (GVI) driver to encapsulate XDMA, optimized PCIe data channels, and used DMA queues to improve throughput.

Resource Limitations on K7:

Challenge: Limited LUTs, DSPs, and DDR3 memory bandwidth.
Solution: Optimized logic resource usage, split complex operations into multiple cycles, and enhanced local BRAM utilization for caching.

Performance Differences Between K7 and U280

Hardware Resources:

U280: UltraScale+ architecture with abundant LUTs, FFs, DSPs, and HBM.
K7: Kintex-7 architecture with limited resources and DDR3 support.

Computational Capability:

U280: Supports multi-cluster, multi-socket, multi-core GPGPU architecture.
K7: Limited to a single cluster, socket, and core due to resource
constraints.

PCIe Support:

U280: PCIe Gen3.
K7: PCIe Gen2.

Optimization on K7

Minimal GPGPU Architecture: Implemented a basic 1-cluster, 1-socket, 1-core architecture, removing non-essential features.
Resource Reuse and Optimization: Shared modules, optimized key paths for common operations (e.g., matrix multiplication), and increased local cache usage.

Impact on System Performance

Throughput and Latency: Lower throughput and higher latency on K7 due to limited resources and lower PCIe bandwidth.
Task Scale: Suitable only for small-scale tasks, not for large deep learning models.
Advantages: Low-cost validation platform, 95% cost reduction, and scalable architecture for future upgrades.

Task Planning and Team Coordination

Task Allocation:

Project Manager: Overall coordination, hardware architecture, system integration, and data flow management.
Tester: Functional and performance testing, OpenCL script execution.
Driver Developer: GVI driver development and debugging.
IP Core Engineer: Optimization and modularization of GPGPU core for K7.

Collaboration Methods:

Tools: Gantt charts, project management tools, enterprise messaging, and knowledge base for documentation.
Meetings: Daily stand-ups and weekly project reviews to synchronize progress and address challenges.
Support: Regular check-ins to assist team members with technical issues and facilitate cross-domain collaboration.

Balancing Hardware and Software Teams:

Clear Interface Definition: Established standardized interfaces and functional requirements between hardware and software.
Milestone Setting: Aligned hardware IP delivery with software driver development and testing.
Communication: Regular joint meetings to ensure consistent understanding of interface requirements and avoid rework.

Overcoming Challenges:

Progress Synchronization: Set short-term goals to avoid delays due to mismatched hardware and software development paces.
Cross-Domain Support: Provided cross-disciplinary technical guidance through documentation and knowledge sharing.

Modular Design in Vivado Block Design

Principles:

Single Responsibility: Each module handles a specific function (e.g., data transfer, GPGPU computation).
Standardized Interfaces: Use AXI4, AXI4-Lite, and AXI4-Stream for module communication.
Hierarchical Design: Organize modules into layers (e.g., data transfer, computation, control) for easier maintenance.

Scalability:

Parameterized Modules: Allow dynamic adjustment of module parameters (e.g., PCIe bandwidth, GPGPU core count).
Reserved Interfaces: Include extra AXI ports and interrupt lines for future expansion.
Flexible Module Replacement: Standardized interfaces enable easy module upgrades.

Maintainability:

Module Packaging: Use Vivado Packager Tool to create reusable IP cores with GUIs for configuration.
Layered Debugging: Develop independent test cases for each module and use simulation tools for verification.
Documentation and Naming: Maintain consistent naming conventions and comprehensive documentation for future reference.

Conclusion

Through clear task allocation, effective tools, and strong team coordination, we successfully overcame technical challenges and deployed the Vortex GPGPU on the K7 FPGA. This project not only validated the feasibility of GPGPU design on resource-constrained hardware but also provided a low-cost platform for future development and expansion.