Why does jackson use the thread-unsafe date class SimpleDateFormat?

[13821042128]

I have encountered a problem. When my program is deserializing, the thread is stuck in the Blocked state. Moreover, the current thread holds a lock, causing a large number of my threads to fall into the BLOCKED state. I don't know why the culprit thread is stuck in BLOCKED state. It already holds the lock but has no competing locks, and it enters the BLOCKED state through the deserialization operation in the synchronization code block. At this point, it is doing the deserialization process of the date string. I guess it's too slow, why use this thread-unsafe SimpleDateFormat class?I'm not sure if my analysis is right, I can provide the stack! The culprit thread above is : http-nio2-9797-exec-57
20230522_103001.txt

[cowtowncoder]

You would need to provide more information on why you think there is actual blockage that causes performance issues. Ideally with reproduction, or at least code sample of code used to call OBjectMapper and with class(es) used as source/target.
As far as I remember, synchronization would only be used when creating a per-readValue/writeValue instance from blueprint, and that should not lead to significant thread contention.
Synchronization is NOT used on individual date value reads/writes, only on creating non-shared copy.

As to why this is used; if you want to provide a replacement that works better feel free to provide PR.
(as I remember JDK only really provides SimpleDateFormat as implementation, but not being thread-safe does require sync'ing of either usage (possibly very expensive for multi-threaded usage) or construction of non-shared instance as needed).

[13821042128]

First of all, thank you very much for your reply. Secondly, I will add my detailed code. My main problem is that I see the http-nio2-9797-exec-57 thread (20230522_103011.txt) in my thread dump according to the json string In the deserialization process of calling objectMapper.readValue(content, valueType) into a UserLoginDTO object, the SimpleDateFormat lock has been obtained, but in the process of deserialization in the sychronized code block inside the objectMapper.readValue method, it enters the BLocked state , after acquiring the SimpleDateFormat lock, it did not acquire resource contention for other locks. My guess is that it entered the Blocked state because of its slow deserialization process (I am not sure, because I analyzed it based on my code and dump For no other reason, the lock resource has been acquired but has entered the BLOCKED state for no reason. I can only guess that it is caused by the deserialization process. I am not sure if I am correct); at the same time, other threads are waiting for the SimpleDateFormat lock. Into the Blocked state.
The question I want to ask is why jackson doesn’t use the thread-safe DateTimeFormatter class (a thread-safe date processing class introduced by java8), or why it doesn’t apply threadLocal to save SimpleDateFormat, one for each thread compared to a large number of high concurrency. Resources are much better. Although there is memory consumption, there should be a big improvement in performance under a large amount of concurrency.
Also, if you have any insight into the problem I'm having, or a clear idea of what's causing it, I'd really appreciate it if you could discuss it with me, because I'm really stumped by this problem!
code.txt
20230522_103001.txt
dump.zip