多线程环境下JAXB反序列化LocalDateTime日期年份异常求助

Hi there, let's break down this odd date parsing problem you're hitting in your multi-threaded batch process. The occasional corrupted year prefixes (like 722008-01-01) on your beginDate field, paired with consistent endDate behavior and inconsistent failures, points to a subtle thread-safety issue somewhere in the deserialization pipeline—not just your adapter's synchronized method.

First, Let's Rule Out Obvious Culprits #

Your LocalDateTimeAdapter looks mostly fine at a glance, but let's dig into potential hidden issues:

1. DateTimeFormatter Thread Safety
   Good news: DateTimeFormatter.ISO_DATE_TIME is thread-safe, so that's not the problem. But to make your adapter more explicit and avoid any accidental static state issues, you can define a static final formatter in your adapter (it's the same under the hood, but clearer).

2. StringUtils Dependencies
   If you're using a custom StringUtils implementation, it might have thread-safety flaws. Replace the StringUtils.isNotBlank(v) check with a native null/empty check to eliminate this variable:

   if (v != null && !v.trim().isEmpty())
   

3. CXF's Adapter Instance Reuse
   CXF often reuses XmlAdapter instances across requests for performance. While your adapter has no instance state, older CXF versions (like 2.7.7) might have edge cases where shared adapter instances interact poorly with thread contexts. Adding logging to track thread IDs and input strings will help you confirm if this is happening.

Modified Adapter with Debug Logging #

Let's update your adapter to add critical debugging context—this will let you see exactly what string is being parsed when failures occur:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class LocalDateTimeAdapter extends XmlAdapter<String, LocalDateTime> {
    private static final Logger logger = LoggerFactory.getLogger(LocalDateTimeAdapter.class);
    private static final DateTimeFormatter DATE_TIME_FORMATTER = DateTimeFormatter.ISO_DATE_TIME;

    @Override
    public LocalDateTime unmarshal(String v) {
        // Log every input string and thread ID to catch corrupted values
        logger.debug("Unmarshalling date string: '{}' [Thread ID: {}]", v, Thread.currentThread().getId());
        
        if (v != null && !v.trim().isEmpty()) {
            try {
                return LocalDateTime.parse(v, DATE_TIME_FORMATTER);
            } catch (Exception exception) {
                logger.error("Failed to parse invalid date string: '{}'", v, exception);
                throw new IllegalArgumentException("Failed to parse date: " + v);
            }
        }
        return null;
    }

    @Override
    public String marshal(LocalDateTime v) {
        if (v != null) {
            return DATE_TIME_FORMATTER.format(v); // Use formatter instead of toString for consistency
        }
        return "";
    }
}

Next Steps to Diagnose the Root Cause #

1. Run Batch Jobs in Single Thread
   Test your batch process in a single-threaded environment. If the issue disappears, you know the problem is tied to multi-threaded resource sharing.

2. Check Shared Input Streams/Resources
   Ensure each thread in your batch process is handling an independent SOAP message input stream. If threads are sharing streams or request contexts, this could cause partial string reads/corruption.

3. Upgrade CXF Version
   CXF 2.7.7 is a very old release (circa 2013) with known thread-safety bugs in its XML parsing pipeline. Upgrading to a newer stable version (like 3.5.x or later) might resolve the issue entirely.

4. Verify CXF Adapter Configuration
   Check if CXF is configured to reuse adapter instances. You can force CXF to create a new adapter per request by adjusting your JAXB bindings or CXF client/server configuration (look for jaxb.adapter.instance related settings).

Why synchronized Didn't Fix It #

Adding synchronized to your unmarshal method only prevents concurrent calls to that method on the same adapter instance. If the corrupted string is already being passed to the adapter (from a thread-unsafe upstream parsing step), the synchronized block won't fix the invalid input—it just ensures only one thread parses it at a time.

内容的提问来源于stack exchange，提问作者cath