[Enhancement] Improve data consistency in DefaultMappedFile flush method

[guyinyou]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Optimize the flush method in DefaultMappedFile to ensure flushed position is only updated after successful disk flush operation, preventing potential data loss scenarios.

Motivation

Currently, the flush method in DefaultMappedFile has a critical data consistency issue where the flushed position is updated regardless of whether the actual disk flush operation succeeds or fails. This creates a dangerous scenario where:

1. The system may incorrectly assume data has been persisted to disk when it's still only in memory
2. If a system crash occurs after a failed flush but before the next successful flush, data could be permanently lost
3. This undermines the reliability guarantees that RocketMQ provides for message persistence

The enhancement is necessary to maintain data integrity and prevent potential message loss, which is critical for a message queue system that prides itself on reliability and durability guarantees.

Describe the Solution You'd Like

Move the FLUSHED_POSITION_UPDATER.set(this, value) call inside the try block of the flush method, ensuring it only executes when the disk flush operation completes successfully.

Current problematic implementation:

try {
    // flush operations
    this.mappedByteBuffer.force();
    this.lastFlushTime = System.currentTimeMillis();
} catch (Throwable e) {
    // error handling
}
FLUSHED_POSITION_UPDATER.set(this, value); // Always executes, even on failure

Proposed solution:

try {
    // flush operations
    this.mappedByteBuffer.force();
    this.lastFlushTime = System.currentTimeMillis();
    FLUSHED_POSITION_UPDATER.set(this, value); // Only executes on success
} catch (Throwable e) {
    // error handling - position not updated on failure
}

Additional improvements:

• Move the isWriteable() check to the beginning of the method to avoid unnecessary operations
• Remove duplicate isWriteable() checks for cleaner code structure

Describe Alternatives You've Considered

1. Adding explicit success/failure tracking: Instead of moving the position update, we could add a boolean flag to track flush success. However, this would add complexity and the current approach is simpler and more reliable.

2. Separating position update into a separate method: We could extract the position update logic into a dedicated method, but this doesn't solve the core issue and adds unnecessary abstraction.

3. Using a different synchronization mechanism: We could use more complex synchronization, but the current atomic updater approach is already optimal for this use case.

4. Adding additional validation: We could add checks to verify the flush actually succeeded, but the try-catch mechanism already provides this validation naturally.

The chosen solution is the most straightforward and effective approach that directly addresses the root cause without introducing additional complexity or performance overhead.

Additional Context

No response