当前上下文中不存在名称怎么解决_Spring中的一些常见操作

在spring中，我们经常会用到事务，也经常会跟数据库打交道，今天我就来说一下自己在开发碰到的一些问题以及解决方法。

1.spring中的事务传播属性

sping中默认的事务传播属性是Propagation.REQUIRED：支持当前事务，如果当前有事务， 那么加入事务， 如果当前没有事务则新建一个。我们写代码的时候，基本上没有考虑事务传播属性，默认也是这个。最多会在事务注解中加上事务管理器的名称，回滚哪些异常类以及超时时间等。

spring中另一些事务传播属性中的一个是Propagation.NOT_SUPPORTED：

以非事务方式执行操作，如果当前存在事务就把当前事务挂起，执行完后恢复事务(忽略当前事务)。

假如有这样的需求：在同一个service中，分别有A B两个方法，方法A的事务传播属性是Propagation.REQUIRED，方法B则是Propagation.NOT_SUPPORTED。在A方法中直接调用方法B，可能会存在问题。由于spring的aop默认是动态代理，所以在service中直接调用方法B，方法B的事务传播属性是失效的，其实此时方法B加入了方法A的事务，跟方法B原初的定义是相违背的。怎么解决这个问题呢？最麻烦也是最一劳永逸的办法，就是使用AspectJ作为spring的aop。最简单粗暴的办法就是从spring的上下文ApplicationContext中获取service的bean,用这个bean去调用方法B。如果觉得从上下文获取bean的方式不友好，可以将无事务的方法抽取到另一个service，原来该怎么调用继续怎么调用。

2.数据库记录的更新丢失

以用户的账户余额进行举例。有A B两个方法，执行不同的业务逻辑，对账户X的金额进行计算并更新。假如在开始，账户余额为100，现在A B两个方法都进行了对账户这个记录进行了查询操作，现在它们看到的都是100。然后经过复杂的且比较耗时的分析和计算，方法A得出最后账户上要加10，方法B得出账户上要减少10.假如A执行的sql是：

UPDATE table SET 余额字段 = 计算后的余额(110) WHERE id = X；

A提交事务。随后B执行sql:

UPDATE table SET 余额字段 = 计算后的余额(90) WHERE id = X；

然后提交事务。

最后账户上的钱就变成了90。按照逻辑来讲账户上的余额还是100才对，因为经过加10和减10操作，余额不变。但是实际的情况是A进行的操作就像丢失了一样，我们称之为更新丢失。

那么我们就疑惑了，平时我们涉及到钱的加减，或者更新的字段值依赖于原值，为什么程序可以照常运行，也没有见到有客户投诉说计算错误啊。其实上面说的是一种小概率事件，A B为什么会同时对账户进行操作呢，最大的可能就是由于客户在屏幕的点击触发的操作。但客户没有影分身，无法同时操作不同的业务逻辑，一般也就不会出问题。可能会出问题的就是一方面客户在屏幕点击触发对账户的操作，同时后台的定时任务，也会触发对账户的操作，那就会有计算错误的可能。但由于定时任务一般都是半夜去跑的，除非客户半夜心猿意马，不点击一下你们公司的app进行账户操作就睡不着觉，那么我们可以说，发生错误的可能性还是很大的。

总之，上面的情况是小概率事件，理论上会发生，实际发生的可能性微乎其微。因为我们不是坏人，想去利用程序漏洞干些什么，我们只会老老实实的进行屏幕点击操作。一般程序的用户寥寥无几，还是被迫去使用这些程序的。当用户激增的时候，这个程序估计会被废弃掉，会由更加厉害和专业的人去写这些东西。绕了一大圈，我们可以安心的喝着可乐，看看小片片了。

但是，我们的好奇心驱使我们一探究竟，想要一劳永逸的把这个问题给解决掉，不要活在乞求上苍保佑的颤抖中。下面呢，是我觉得可能会有效的思路：

A.在查询的时候就让数据库锁住该行

常用的就是SELECT * FROM table WHERE id = X FOR UPDATE;

使用FOR UPDATE锁住该行记录，直到本次事务提交或者回滚之后，下一个的查询该行的事务才可以继续运行。也就是在查询的时候，我就只有一个线程操作了，接下来的什么问题都解决了。但是这样性能太差，在操作这行数据的时候，竟然连普通的列表查询也干不了了，这可不行，如果业务逻辑执行时间很长，那么锁住该行的时间也很长，其余的涉及到会查询到该行的事务全部停滞不前。虽然解决方式很简洁，但是性能的代价也很高。同时如果更新多张表，会因为锁的次序不一致，导致死锁的发生。

B. 使用乐观锁 上面的FOR UPDATE其实是悲观锁，总认为后续操作都会更改值，但实际上大多数操作都是查询，涉及的更改很少。因此使用乐观锁来控制，谁先更新谁成功，后续的都失败，要么放弃，要么重试。假如A 对该记录做了更改:

UPDATE table SET 字段=新值,SET version = version + 1 WHERE id = X AND version = 当时查询的值version；

并提交事务。随后的事务也进行类似的提交，但是数据库的version已经改变，事务B根据WHERE条件更新，是不会影响到任何行的，受影响的行返回值等于0，也就是事务B是提交失败的。

使用乐观锁以不断重试为代价，换来了后台性能的极大提升。

C. 使用锁 所有对该记录的操作都使用同一把锁。对于单机可以使用java自带的锁就可以，对于分布式的，需要使用分布式锁。使用锁保证了同一时间，只有一个线程进行资源操作。方式简单易懂，缺点是需要所有人都要一致的进行使用锁，只要有一个地方没有使用锁，或者使用错了，或者没有释放锁，或者错误释放锁，死锁，都会造成错误。类似于，想要正确性，需要所有地方的维护，但是产生错误，只要有一个地方的错误就够了。

D. 从实际出发 将乐观锁和程序中的锁结合起来使用，最大限度保证程序的正确性。多人合作开发，代码质量和业务逻辑理解经常是参差不齐的，所以结合起来使用是一种折中的解决方案。