ConcurrentSkipListMap条目锁定及Pair.of死锁排查技术问询

咱们一步步拆解你遇到的问题，从构造器的安全性到lrPoints方法的故障点，再到静态初始化死锁的可能性：

一、构造器是否能避免客户端Map锁定？ #

答案是不能完全避免。

TimeSeries的构造器通过series.putAll(m)复制客户端传入的Map内容，但这个复制过程的行为完全取决于客户端传入的Map类型：

• 如果客户端传入的是非线程安全的Map（比如普通TreeMap/HashMap），此时若其他线程正在修改这个Map，putAll遍历条目时可能抛出ConcurrentModificationException，但不会直接导致停滞；
• 如果客户端传入的是同步包装的Map（比如Collections.synchronizedMap）或者自定义的带锁Map，当其他线程持有该Map的锁时，putAll会阻塞等待锁释放，这就会导致TimeSeries的构造过程停滞。

不过从你描述的“get方法可正常返回”来看，构造阶段应该已经完成，所以停滞问题大概率不是出在构造器环节。

二、lrPoints方法的可能失败原因 #

先看lrPoints的代码逻辑：它没有任何循环结构，所以无限循环的可能性可以排除。那停滞的原因更偏向死锁或者阻塞，重点看这几个环节：

1. ConcurrentSkipListMap的方法调用：firstKey()、lastKey()、floorEntry()、ceilingEntry()都是ConcurrentSkipListMap的线程安全方法，基于CAS实现，本身不会产生死锁，但它们是弱一致性的——比如在判断t的范围和调用floorEntry之间，其他线程可能修改了series的内容，但这种情况只会导致异常，不会让方法停滞。
2. Pair.of()的静态方法调用：这是你后来定位到的关键点。Apache Commons的Pair.of()是静态工厂方法，首次调用时会触发Pair类（或其内部实现类，比如ImmutablePair）的静态初始化。如果静态初始化过程中出现了阻塞或死锁，就会让整个lrPoints方法停滞。

三、静态初始化器导致死锁的可能性 #

静态初始化死锁是很容易被忽略的坑，JVM在加载类时会给每个类分配一个初始化锁：当一个线程正在初始化类时，其他线程访问该类的静态成员都会被阻塞等待初始化完成。如果出现类初始化的循环依赖，就会触发死锁：
举个典型场景：

• 线程1调用Pair.of()，触发Pair类的静态初始化，此时线程1持有Pair的初始化锁；
• Pair的静态初始化代码中调用了类X的静态方法；
• 线程2此时正在触发类X的静态初始化，而类X的初始化代码中又需要访问TimeSeries的某个静态成员，恰好TimeSeries的初始化又依赖Pair类；
  这样就形成了循环等待，两个线程都卡住，最终导致lrPoints方法无法退出。

另外，如果Pair的静态初始化过程中需要等待某个外部锁（比如数据库连接锁、文件锁），而该锁被其他线程持有且无法释放，也会导致调用Pair.of()的线程停滞。

总结 #

1. 构造器无法避免客户端Map的锁竞争，但你的问题中get方法正常，所以不是构造阶段的问题；
2. lrPoints方法本身没有无限循环，停滞的核心原因大概率是Pair.of()触发的静态初始化死锁；
3. 建议排查Pair类及其依赖类的静态初始化逻辑，看是否存在循环依赖或阻塞等待外部资源的情况。

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