『导致查询数据库结果一致，为“可以支付”！则生成2条支付记录信息』
这句话说明你检测数据一致性和数据更改落实没有在一个数据库事务周期内完成。
你应该提高隔离级别如：
1、Connection..setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
2、Connection.setAutocommint(false);
3、查询数据是否存在；
4、插入纪录，如果需要；
5、Connection.commit()或者Connection.rollback();

实际上是这样的：第一个请求到达，服务器查询后允许支付，此时后台进入第一个请求的支付处理逻辑，在这时第二个请求到达，因第一个请求刚开始处理并未处理完成，数据库数据并未产生变化，所以也得到可以支付的判定，第二个请求也进了支付逻辑=。=

感觉楼主说的更像是表单重复提交问题吧？如果用户刻意的在点击一条之后，服务端生成相应数据并反馈后，再次点击，那肯定要按逻辑服务端再生成数据，谁让他点两次呢？如果说是由于网络问题用户频繁的点击提交，为预防这种情况可以做个防止表单重复提交的拦截

也可以类似支付宝那种，当你点击支付后，直接弹出另一个页面，而本页面立即变为：支付成功or失败？  这样也可以防止其重复提交

有点类似，但不是表单重复提交，客户端是Android，第二次请求是客户端主动取消等待界面，关闭后再次发起的一个请求，对于服务器和客户端来说都是新请求不是重复提交。我现在的临时解决方案是客户端加大超时时间，同时点击提交后锁定界面，不允许在超时前再发起请求。治标不治本吧

既然楼主允许主动取消再提交的话，那就只能是服务器端作判断了，当服务器端收到请求时，判断一下是否请求已经处理过了，至于判断规则，可以在手机发送时优先生成一个请求序列UUID，如果取消再提交，则UUID不变，否则每次UUID都改变

数据库事务还没commit，下一个交易过来，查询数据库还是没update的数据，所以出问题

这种情况下最好权衡一下你们系统的性能和一致性需求，如果性能可以接受，数据库加行级甚至表一级锁，这样下一个交易来只有等上一交易commit才查得到数据，如果性能是优先考虑，那只有加其他的判断依据了

可以考虑锁行，不给读，结算涉及的表有好几个，锁行也要锁N多个，而且锁表会影响其他业务的效率

不管怎么做，最终一定是在某个统一的地方做互斥的。比如：
1、为你的消费记录增加一个字段，标记是否已开始支付，甚至就记录支付请求的序列号，每当发起支付请求时首先更改该字段用以避免新的请求再次发起，更好的体验是新的请求会还原刚才中断的操作，继续后续的流程；
2、虽然你说支付记录可以被1：N，不能加锁，但是你可以创建一个新的支付流水表用来锁定某个消费记录的互斥状态，生命周期可以很短，代价不算高；
等等等。
所以解决的思路大致是，如果现有的结构能够找到一个切入点加锁就用现有的，如果没有就刻意增加一个数据存储，迫使记录与数据对应，用这个新的数据加锁。这有点类似文件的情况，有一个test.dat文件，很多进程都要读写，为了避免冲突，会在操作文件时创建test.lck文件用于被其他进程发现，该文件已经处于被操作状态，这个过程中的互斥并没有改变目标文件的任何内容，而是通过外部数据加锁。

更改字段的时候就并发了怎么办？两个线程同时获得这个字段发现当前是未开始支付

配置事务的隔离级别为read committed（能读到不同事务已提交到的数据）可以解决你的问题

客户端增加交易流水号，服务端使用一个表记录此流水号交易状态，首次收到请求时先设定此流水号为正在操作中，服务端执行完成，修改此流水号的执行结果状态。可以简化主业务数据库的锁表

思路还是行锁，对吧？

只要涉及到数据库且不锁，就可能会存在对同一组数据的并发读写=。= ，如果正在更新流水号时产生并发读，结果是一样的

流水号表锁表比交易数据相关表锁表多系统影响轻很多