陷阱

Java的Comparable接口提供一个对实现了这个接口的对象列表进行排序的办法。原始的排序对于简单的对象来说具有意义，但是当我们面对复杂的面向对象的业务逻辑对象时，事情变得复杂的多。从业务经理的角度来看，一些交易对象的自然顺序可能是按照交易的价值来排序的，但是从系统管理员的角度来看，这个排序的规则可能是交易的速度。所以在大多数情况下，并没有明确的业务领域对象的自然排序规则。 假设我们找到了一个需要排序的类，比如说Campany。我们把公司的offical name作为主关键字，把id作为次要关键字。这个类的实现如下： public class Company implements Comparable<Company> { private final String id; private final String officialName; public Company(final String id, final String officialName) { this.id = id; this.officialName = officialName; } public String getId() { return id; } public String getOfficialName() { return officialName; } @Override public

问题产生场景： 昨天支付中心发起退款回调时，引起了我们这边一个bug： 有两笔退款异常，支付中心发起第一笔异常的回调的时候就把我们这边两笔退款异常对应的订单的状态全部给修改 了。当支付中心对第二笔异常回调的时候回调程序发现订单状态已经改变发出了一个异常邮件，然后回调就终止 了，所以数据库呈一个不一致状态：订单状态已改变，但没有记录订单日志，也没有记录退款状态。然后大家就来寻找这个bug，过程挺有意思的。 首先我们请DBA从订单号，订单Id和时间多个条件查数据库的日志，想找出是哪个系统发出的这个更新订单状态的log，最后没找到。 后来从退款回调里发现下面的代码： checkUpdateResult(updateDAO.execute( "order.updateStatus", ImmutableMap.of("orderId", order.getId(), "updateTs", TsUtils.now(), "preStatus", currStatus.getStatus(), "currentStatus",nextStatus.getStatus())) ) 这是用于更新订单状态的代码，传入了参数 orderId, updateTs,preStatus对应的mybatis mapper： <update id="updateStatus" parameterType=