[Bug] Resource leak in DumpCompactionLogCommand - RandomAccessFile and FileChannel never closed

[daguimu]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

All platforms

RocketMQ version

develop branch (latest)

JDK Version

JDK 8+

Describe the Bug

In DumpCompactionLogCommand.java, a RandomAccessFile is created to obtain a FileChannel, but neither the RandomAccessFile nor the FileChannel is ever closed:

FileChannel fileChannel = new RandomAccessFile(fileName, "rw").getChannel();
ByteBuffer buf = fileChannel.map(MapMode.READ_WRITE, 0, fileSize);
// ... use buf ...
UtilAll.cleanBuffer(buf);
// fileChannel and RandomAccessFile are never closed

The anonymous RandomAccessFile instance is immediately discarded after calling .getChannel(), making it impossible to close later. The FileChannel obtained from it is also never closed. This leaks file descriptors.

Steps to Reproduce

Run the DumpCompactionLogCommand tool to dump a compaction log file. After execution, the file descriptor remains open.

What Did You Expect to See?

The RandomAccessFile and FileChannel should be properly closed after use, ideally using try-with-resources.

What Did You See Instead?

File descriptors are leaked because neither resource is closed.

Additional Context

The fix should use try-with-resources to ensure both the RandomAccessFile and FileChannel are properly closed.