guyinyou opened a new issue, #9841: URL: https://github.com/apache/rocketmq/issues/9841
### Before Creating the Enhancement Request - [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature. ### Summary This enhancement improves the resource management lifecycle in `TimerWheel` class by properly managing `RandomAccessFile` and `FileChannel` resources throughout the object's lifetime, preventing file handle leaks that can occur when resources are closed prematurely in the constructor. ### Motivation The current implementation of `TimerWheel` creates `RandomAccessFile` and `FileChannel` as local variables in the constructor and closes them in a `finally` block immediately after mapping the file. ### Describe the Solution You'd Like 1. **Convert local variables to instance variables**: Move `RandomAccessFile` and `FileChannel` from local variables in the constructor to instance fields of the `TimerWheel` class. 2. **Remove premature resource closure**: Remove the `finally` block in the constructor that closes `RandomAccessFile`, allowing the resources to remain open throughout the object's lifetime. 3. **Add proper cleanup in shutdown()**: Add logic in the `shutdown()` method to properly close the `FileChannel` (and implicitly the `RandomAccessFile`) when the `TimerWheel` is being shut down. ### Describe Alternatives You've Considered 1. **Using try-with-resources**: Considered using try-with-resources for automatic resource management, but this would close resources too early since the `MappedByteBuffer` needs the underlying channel to remain open. 2. **Keeping resources local but passing to shutdown()**: Considered keeping resources as local variables but passing them to a cleanup method. However, this approach is less clean and doesn't align with object-oriented design principles. 3. **Using a separate ResourceManager**: Considered creating a separate resource manager class, but this adds unnecessary complexity for a single class with straightforward resource management needs. 4. **Delayed initialization pattern**: Considered lazy initialization, but the resources are needed immediately during construction, so this doesn't provide benefits. The chosen solution (instance variables with cleanup in `shutdown()`) is the most straightforward and aligns with the existing codebase patterns while ensuring proper resource lifecycle management. ### Additional Context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
