LuciferYang opened a new pull request, #3447:
URL: https://github.com/apache/parquet-java/pull/3447

   ### Rationale for this change
   Fixes #3398
   
   In `FromCharSequenceBinary`, a `ThreadLocal<CharsetEncoder>` is initialized 
via `ThreadLocal.withInitial(StandardCharsets.UTF_8::newEncoder)`. The lambda 
generates a dynamic `Supplier` class loaded by the current application 
ClassLoader. In long-lived thread pool environments (Spark/Flink executors, web 
containers), pooled worker threads survive job cancellation or 
hot-redeployment, retaining a strong reference chain: `Thread` → 
`ThreadLocalMap` → `SuppliedThreadLocal` → lambda → ClassLoader. This 
permanently pins the application ClassLoader, preventing class unloading and 
causing linear Metaspace growth, eventually leading to 
`java.lang.OutOfMemoryError: Metaspace`.
   
    
   ### What changes are included in this PR?
   Replaced the `ThreadLocal<CharsetEncoder>` based encoding in 
`FromCharSequenceBinary` with a stateless 
`value.toString().getBytes(StandardCharsets.UTF_8)`, consistent with the 
existing `FromStringBinary.encodeUTF8()` at line 251 in the same file. 
   
   Also note that the original `catch (CharacterCodingException)` block was 
effectively dead code — `StandardCharsets.UTF_8` is a standard charset 
guaranteed to be available, so `CharsetEncoder.encode()` would never throw 
`CharacterCodingException` for unsupported charset reasons.
   
   ### Are these changes tested?
     Yes. All existing tests in `parquet-column`  pass without modification.
   
   
   ### Are there any user-facing changes?
   No. The encoding behavior is identical — both approaches produce the same 
UTF-8 byte sequence.
   
   **Performance note**: `fromCharSequence()` is only invoked as a fallback in 
`AvroWriteSupport.fromAvroString()` for non-String, non-Utf8 `CharSequence` 
implementations. The dominant write paths use `fromReusedByteArray()` (Avro 
`Utf8`) and `fromString()` (Java `String`), both of which already use stateless 
encoding without `ThreadLocal`. Therefore, no measurable performance regression 
is expected.


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to