最近工程中发现一个奇怪的问题,简单代码逻辑如下所示:
@EnableScheduling
@Component
public class SimpleImplement {
private static final Logger LOG = LoggerFactory.getLogger(SimpleImplement.class);
private volatile List<String> list = Collections.EMPTY_LIST;
private final Queue<Thread> waiters = Queues.newConcurrentLinkedQueue();
// 如果list为空挂起线程
public List<String> get(){
while(CollectionUtils.isEmpty(list)){
try {
Thread current = Thread.currentThread();
waiters.add(current);
LOG.info("list 为空挂起线程 {}.", current.getName());
LockSupport.park();
}catch (Exception e){}
}
return list;
}
// 异步更新list,如果list不为空则唤醒被挂起的线程
@Scheduled(fixedDelay = 1000)
private void sync(){
// 加载数据
list = ...;
if(CollectionUtils.isNotEmpty(list)){
Thread waiter = null;
while (!waiters.isEmpty()){
waiter = waiters.remove();
LOG.info("同步数据 list 不为空唤醒线程 {}.", waiter.getName());
LockSupport.unpark(waiter);
}
}
}
上边代码对list异步加载,调用get接口的时候如果list为空就挂起当前线程,待有数据加载时再进行唤醒。我们知道加锁也可以实现等待唤醒,这里用LockSupport是因为这里是异步加载数据不存在数据竞争问题,加锁会让多个线程串行执行,影响任务执行效率。
问题
get()接口在工程中好几处被调用,测试发现被挂起的线程有时会唤醒失败。反复测试几次从日志中看被阻塞的线程都是 scheduling-1,看起像是定时器的线程。于是翻看了代码发现几处调用get()接口的地方都采用@Scheduled注解进行周期轮询。
分析
怀疑这里可能是@Scheduled的实现是单线程,几处定时任务都是有同一个线程执行,如果这样调用sync()接口的线程也是调用get()接口的线程,如果被阻塞那么唤醒动作就一直得不到执行。
验证
为了验证我们的想法,写了个简单的测试代码及结果如下:
@Component
@EnableScheduling
public class ScheduledTest {
private static Logger LOG = LoggerFactory.getLogger(ScheduledTest.class);
@Scheduled(fixedDelay = 1000)
public void method1(){
LOG.info("线程 {} 执行method1 .", Thread.currentThread().getName());
}
@Scheduled(fixedDelay = 1000)
public void method2(){
LOG.info("线程 {} 执行method2 .", Thread.currentThread().getName());
}
}
测试发现@Scheduled注解确实是单线程执行,执行method1和method2的线程都是scheduing-1,并且在打印完method1执行的log后5秒才打印method2的log,说明在这里scheduling-1在method1被阻塞了5秒。
这里刚好验证了我们的猜想:被挂起的线程没有被唤醒,是因为执行唤醒和被挂起的是同一个线程。
现在已经确定问题了,接下来就是怎么改。改之前去翻看下源码找到问题的根源,才能更好的解决问题,源码分析接下篇《Spring @Scheduled线程模型探究 - 源码追踪》。