今天跟大家聊聊日常开发中，如何减少bug？本文将从数据库、代码层面、缓存使用篇3个大方向，总结出一共50多个注意点，助大家成为开发质量之星。

慢查询

数据库篇的话，哪些地方容易导致bug出现呢？我总结了7个方面：慢查询、数据库字段注意点、事务失效的场景、死锁、主从延迟、新老数据兼容、一些SQL经典注意点。

慢查询

1）是否命中索引

提起慢查询，我们马上就会想到加索引。如果一条SQL没加索引，或者没有命中索引的话，就会产生慢查询。

2） 数据量大，考虑分库分表

单表数据量太大，就会影响SQL执行性能。我们知道索引数据结构一般是B+树，一棵高度为3的B+树，大概可以存储两千万的数据。超过这个数的话，B+树要变高，查询性能会下降。

因此，数据量大的时候，建议分库分表。分库分表的中间件有mycat、sharding-jdbc

3）不合理的SQL

日常开发中，笔者见过很多不合理的SQL：比如一个SQL居然用了6个表连接，连表太多会影响查询性能；再比如一个表，居然加了10个索引等等。索引是会降低了插入和更新SQL性能，所以索引一般不建议太多，一般不能超过五个。

数据库字段这块内容，很容易出bug。比如，你测试环境修改了表结构，加了某个字段，忘记把脚本带到生产环境，那发版肯定有问题了。

1）字段是否会超长

假设你的数据库字段是：

`name` varchar(255) DEFAULT NOT NULL

如果请求参数来了变量name，字段长度是300，那插入表的时候就报错了。所以需要校验参数，防止字段超长。

2）字段为空，是否会导致空指针等

我们设计数据库表字段的时候,尽量把字段设置为not null。

如果数据库字段设置为NULL值，容易导致程序空指针；如果数据库字段设置为NULL值，需要注意count(具体列) 的使用，会有坑。

3）字段缺失

我们的日常开发任务，如果在测试环境，对表进行修改，比如添加了一个新字段，必须要把SQL脚本带到生产环境，否则字段缺失，发版就有问题啦。

4）字段类型是否支持表情

如果一个表字段需要支持表情存储，使用utf8mb4。

5）谨慎使用text、blob字段

如果你要用一个字段存储文件，考虑存储文件的路径，而不是保存整个文件下去。使用text时，涉及查询条件时，注意创建前缀索引。

1）@Transactional 在非public修饰的方法上失效

@Transactional注解，加在非public修饰的方法上，事务是不会生效的。spring事务是借鉴了AOP的思想，也是通过动态代理来实现的。spring事务自己在调用动态代理之前，已经对非public方法过滤了，所以非public方法，事务不生效。

2）本地方法直接调用

以下这个场景，@Transactional事务也是无效的

public class TransactionTest{  public void A(){    //插入一条数据    //调用方法B (本地的类调用，事务失效了)    B();  }    @Transactional  public void B(){    //插入数据  }}

3）异常被try...catch吃了，导致事务失效

4）rollbackFor属性设置错误

Spring默认抛出了未检查unchecked异常（继承自RuntimeException 的异常）或者Error才回滚事务；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，就需要指定rollbackFor属性。

5）底层数据库引擎不支持事务

MyISAM存储引擎不支持事务，InnoDb就支持事务

6）spring事务和业务逻辑代码必须在一个线程中

业务代码要和spring事务的源码在同一个线程中，才会受spring事务的控制。比如下面代码，方法mothed的子线程，内部执行的事务操作，将不受mothed方法上spring事务的控制，这一点大家要注意。这是因为spring事务实现中使用了ThreadLocal，实现同一个线程中数据共享。

@Transactionalpublic void mothed() {    new Thread() {      事务操作    }.start();}

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。

MySQL内部有一套死锁检测机制，一旦发生死锁会立即回滚一个事务，让另一个事务执行下去。但死锁有资源的利用率降低、进程得不到正确结果等危害。

1）9种情况的SQL加锁分析

要避免死锁，需要学会分析：一条SQL的加锁是如何进行的?一条SQL加锁，可以分9种情况进行探讨：

2）如何分析解决死锁？

分析解决死锁的步骤如下：

1）要求强一致性，考虑读主库

如果是重要业务，要求强一致性，考虑直接读主库

2）不要求强一致性，读从库

如果是一般业务，可以接受短暂的数据不一致的话，优先考虑读从库。因为从库可以分担主库的读写压力，提高系统吞吐。

1）新加的字段，考虑存量数据的默认值

1）limit大分页问题

limit大分页是一个非常经典的SQL问题，我们一般有这3种对应的解决方案

方案一：如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit

select id,name from employee where id>1000000 limit 10.

方案二：在业务允许的情况下限制页数：

建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。谷歌搜索页也是限制了页数，因此不存在limit大分页问题。

方案三：利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联）

SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id

2）修改、查询数据量多时，考虑分批进行

我们更新或者查询数据库数据时，尽量避免循环去操作数据库，可以考虑分批进行。比如你要插入10万数据的话，可以一次插入500条，执行200次。

正例：

remoteBatchQuery(param);

反例：

for(int i=0;i<100000;i++){  remoteSingleQuery(param)}

代码层面

编码细节.gif

1）六大典型空指针问题

我们编码的时候，需要注意这六种类型的空指针问题

if(object!=null){   String name = object.getName();}

2）线程池使用注意点

使用 Executors.newFixedThreadPool，可能会出现OOM问题，因为它使用的是无界阻塞队列，建议使用自定义的线程池，最好给线程池一个清晰的命名，方便排查问题。

不同的业务，最好做线程池隔离，避免所有的业务公用一个线程池。

线程池异常处理要考虑好。

3）线性安全的集合、类

在高并发场景下，HashMap可能会出现死循环。因为它是非线性安全的，可以考虑使用ConcurrentHashMap。所以我们使用这些集合的时候，需要注意是不是线性安全的。

Hashmap、Arraylist、LinkedList、TreeMap等都是线性不安全的；

Vector、Hashtable、ConcurrentHashMap等都是线性安全的

4）日期格式，金额处理精度等

日常开发，经常需要对日期格式化，但是呢，年份设置为YYYY大写的时候，是有坑的哦。

Calendar calendar = Calendar.getInstance();calendar.set(2019, Calendar.DECEMBER, 31);

Date testDate = calendar.getTime();

SimpleDateFormat dtf = new SimpleDateFormat("YYYY-MM-dd");System.out.println("2019-12-31 转 YYYY-MM-dd 格式后 " + dtf.format(testDate));

运行结果：

2019-12-31 转 YYYY-MM-dd 格式后 2020-12-31

还有金额计算也比较常见，我们要注意精度问题：

public class DoubleTest {    public static void main(String[] args) {        System.out.println(0.1+0.2);        System.out.println(1.0-0.8);        System.out.println(4.015*100);        System.out.println(123.3/100);

        double amount1 = 3.15;        double amount2 = 2.10;        if (amount1 - amount2 == 1.05){            System.out.println("OK");        }    }}

运行结果：

0.300000000000000040.19999999999999996401.499999999999941.2329999999999999

5）大文件处理

读取大文件的时候，不要Files.readAllBytes直接读到内存，会OOM的，建议使用BufferedReader一行一行来，或者使用NIO

6）使用完IO资源流，需要关闭

使用try-with-resource，读写完文件，需要关闭流

/* * 关注公众号，dbaplus社群 */try (FileInputStream inputStream = new FileInputStream(new File("jay.txt")) {    // use resources   } catch (FileNotFoundException e) {    log.error(e);} catch (IOException e) {    log.error(e);}

7） try...catch异常使用的一些坑

8）先查询，再更新/删除的并发一致性

日常开发中，这种代码实现经常可见：先查询是否有剩余可用的票，再去更新票余量。

if(selectIsAvailable(ticketId){     1、deleteTicketById(ticketId)     2、给现金增加操作 }else{     return “没有可用现金券” }

如果是并发执行，很可能有问题的，应该利用数据库更新/删除的原子性，正解如下：

if(deleteAvailableTicketById(ticketId) == 1){     1、给现金增加操作 }else{     return “没有可用现金券”

1）校验参数合法性

我们提供对外的接口，不管是提供给客户端、还是前端，又或是别的系统调用，都需要校验一下入参的合法性。

如果你的数据库字段设置为varchar(16),对方传了一个32位的字符串过来，你不校验参数长度，插入数据库直接异常了。

2）新老接口兼容

一般幂等技术方案有这几种:

接口幂等性.gif

1）超时处理

我们调用别人的接口，如果超时了怎么办呢？

2）考虑重试机制

使用缓存，可以降低耗时，提供系统吞吐性能。但是，使用缓存，会存在数据一致性的问题。

1）几种缓存使用模式

一般我们使用缓存，都是旁路缓存模式，读请求流程如下:

旁路缓存模式的写流程：

2）删除缓存呢，还是更新缓存？

我们在操作缓存的时候，到底应该删除缓存还是更新缓存呢？我们先来看个例子：

这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。

3）先操作数据库还是先操作缓存

双写的情况下，先操作数据库还是先操作缓存？我们再来看一个例子：假设有A、B两个请求，请求A做更新操作，请求B做查询读取操作。

酱紫就有问题啦，缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此，Cache-Aside缓存模式，选择了先操作数据库而不是先操作缓存。

4）如何保证最终一致性

缓存穿透：指查询一个一定不存在的数据，由于缓存不命中时，需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。”

缓存穿透一般都是这几种情况产生的：业务不合理的设计、业务/运维/开发失误的操作、黑客非法请求攻击。如何避免缓存穿透呢？一般有三种方法。

缓存雪崩：指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。”

缓存雪奔一般是由于大量数据同时过期造成的，对于这个原因，可通过均匀设置过期时间解决，即让过期时间相对离散一点。如采用一个较大固定值+一个较小的随机值，5小时+0到1800秒酱紫。

Redis 故障宕机也可能引起缓存雪奔。这就需要构造Redis高可用集群啦。

缓存击穿：指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。”

缓存击穿看着有点像缓存雪崩，其实它两区别是，缓存雪奔是指数据库压力过大甚至down机，缓存击穿只是大量并发请求到了DB数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别，是在于击穿针对某一热点key缓存，雪奔则是很多key。

解决方案就有两种：

在Redis中，我们把访问频率高的key，称为热点key。如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。

如何解决热key问题？

1）评估容量，合理利用

如果我们使用的是Redis，而Redis的内存是比较昂贵的，我们不要什么数据都往Redis里面塞，一般Redis只缓存查询比较频繁的数据。同时，我们要合理评估Redis的容量，也避免频繁set覆盖，导致设置了过期时间的key失效。

如果我们使用的是本地缓存，如guava的本地缓存，也要评估下容量。避免容量不够。

2）Redis的八种内存淘汰机制

为了避免Redis内存不够用，Redis用8种内存淘汰策略保护自己~

3）不同的业务场景，Redis选择适合的数据结构

• 不能使用 keys指令

• 慎用O(n)复杂度命令，如hgetall等

• 慎用Redis的monitor命令

• 禁止使用flushall、flushdb

• 注意使用del命令