有这样一个需求，生产者将消息存入数据库，并放入队列中等待处理。消费者获取并处理消息，将更新后的消息存入数据库。
主键策略为id自增
伪代码如下
...
//生产者线程
email.setStatus(SANDING); //设置邮件的状态为正在发送 ......1
email = emailRepository.save(email); //将邮件插入数据库，取得带有id的实体 ......2
queue.add(email); //把邮件放入队列 ......3
...
...
//消费者线程
Email email = queue.poll(); //从队列中取出邮件 ......1
try {
send(email); //发送邮件 ......2
email.setStatus(SUCCESS); //设置邮件的状态为发送成功 ......3
} catch (Exception e) {
email.setStatus(FAIL); //失败则设置邮件的状态为发送失败 ......4
e.printStackTrace()
}
emailRepository.save(email); //更新邮件状态 ......5
然而消费者线程中的 5 并没有更新记录，而是插入一条新的记录。
也许是两次save间隔太短了吧，想起多线程的常用解决方案，不行就睡，于是将消费者线程改造了一下
Thread.sleep(1000);
emailRepository.save(email); //更新邮件状态 ......5
好了，一切正常。
作为一个打破沙锅问到底的人，问题虽然解决，但还是要弄清楚问题发生的原因
继续改造消费者线程
// 实验一
...
System.out.println(email); // 输出 Email{id=345 ...
Thread.sleep(1000);
email = emailRepository.save(email); //更新邮件状态 ......5
System.out.println(email); // 输出 Email{id=345 ...
//实验二
..
System.out.println(email); // 输出 Email{id=455 ...
email = emailRepository.save(email); //更新邮件状态 ......5
System.out.println(email); //输出 Email{id=456 ...
生产者线程的 2 切切实实是先执行于消费者线程的 5 ，这就奇怪了，明明已经保存好的数据，再save时居然是插入操作。难道生产者线程的 2 执行之后返回了email，但是没有立即将数据插入数据库吗？ 继续我们的实验
//实验三
...
Email email = emailRepository.findById(email.getId()).orElse(new Email());
System.out.println(email.toString()); //输出 Email{id=null ...
email = emailRepository.save(email); //更新邮件状态 ......5
问题明确了，生产者线程事务结束后，消费者线程没有立即读到生产者线程事务的结果，认为email是一个新的数据，插入到了数据库中。
使用save()之后究竟发生了什么，看看源码
save()的实现在SimpleJpaRepository中
@Transactional
public <S extends T> S save(S entity) {
if (entityInformation.isNew(entity)) { ...1
em.persist(entity); ...2
return entity;
} else {
return em.merge(entity); ...3
}
}
具体逻辑：
...1 这是一个新实例吗，如何判断这是一个新的实例呢。1.主键为空则为新实例。2.如果id是Number的子类，id == 0则为新实例
public boolean isNew(T entity) {
ID id = getId(entity);
Class<ID> idType = getIdType();
if (!idType.isPrimitive()) {
return id == null;
}
if (id instanceof Number) {
return ((Number) id).longValue() == 0L;
}
throw new IllegalArgumentException(String.format("Unsupported primitive id type %s!", idType));
}
...2 是新实例则persist
...3 不是则merge
merge执行的sql是这样的，先select看看数据库中有没有实例中的id对应的记录，有则update，无则insert
然而，jpa不保证save()之后返回的entity可以立即被find()发现(相当于insert一条记录后不能被立即select出来)。经实验，save()执行后需要20-70毫秒的时间将数据持久化到数据库
使用sleep睡100毫秒可以保证数据持久化的时间，但这无法将性能压榨到极致，而且如果持久化的时间超过100毫秒，仍然find()不到save()的数据。
经过千辛万苦的查找，在mysql文档中找到了这个，Locking Reads
(https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html)
使用select ...for update或者select ...for share可以等待其它事务数据被提交(Commit)后才会执行select
原文如下
If any of these rows were changed by another transaction that has not yet committed,
your query waits until that transaction ends and then uses the latest values.
jpa中@Lock可以在查询时添加悲观锁，乐观锁。其原理是通过修改执行的sql语句，在数据库层面加锁
于是我们重写EmailRepository的findById()
@Override
@Lock(LockModeType.PESSIMISTIC_READ)
Optional<Email> findById(Long id);
继续实验三的代码
//实验三
...
Email email = emailRepository.findById(email.getId()).orElse(new Email());
System.out.println(email.toString()); //输出 Email{id=455 ...
email = emailRepository.save(email); //更新邮件状态 ......5
这时候我们发现可以读到最新更新的数据，通过show-sql查看findById()执行的sql为select... in share mode。
(ps: select ...for share和select ...in share mode功能相似)
于是如下修改消费者线程
...
//消费者线程
Email email = queue.poll(); //从队列中取出邮件 ......1
try {
send(email); //发送邮件 ......2
email.setStatus(SUCCESS); //设置邮件的状态为发送成功 ......3
} catch (Exception e) {
email.setStatus(FAIL); //失败则设置邮件的状态为发送失败 ......4
e.printStackTrace()
}
emailRepository.findById(email.getId()); //保证自己能读到最新的数据，也同时保证了下面的save()执行select语句时不会拿到空数据
emailRepository.save(email); //更新邮件状态 ......5
这样生产者线程save()的数据就可以立即无等待地获取了
