转载自：https://baijiahao.baidu.com/s?id=1688631517911751367&wfr=spider&for=pc 此文作用于自己刷题使用，答案在每道题的题干后面的括号中，选中即可显示。

A .测试数据入库时加特殊前缀标识。

B .测试数据使用独立的测试库。

C .自动回滚单元测试产生的脏数据。

D .无须区别，统一在业务代码中进行判断和识别。

简单解析：P29 【推荐】：和数据库相关的单元测试，可以设定自动回滚机制，不给数据库造成脏数据。或者对单元测试产生的数据有明确的前后缀标识。 正例：在企业智能事业部的内部单元测试中，使用 ENTERPRISE_INTELLIGENCE _UNIT_TEST_的前缀来标识单元测试相关代码。

A .线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

B .同步处理时，能锁部分代码区块的情况下不要锁整个方法；高并发时，同步调用应该考虑到性能损耗。

C .创建线程或线程池时，推荐给线程指定一个有意义的名称，方便出错时回溯。

D .推荐使用Executors.newFixedThreadPool(int x)生成指定大小的线程池。(线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式)

简单解析： P15【强制】：线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。 说明：Executors 返回的线程池对象的弊端如下： 1） FixedThreadPool 和 SingleThreadPool：允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。 2） CachedThreadPool：允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM。

【强制】：线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。 说明：线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

【强制】：高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。 说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。

P14【强制】：创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。 正例：自定义线程工厂，并且根据外部特征进行分组，比如机房信息。

A .对于“明确停止使用的代码和配置”，如方法、变量、类、配置文件、动态配置属性等要坚决从程序中清理出去，避免造成过多垃圾。

B .永久弃用的代码段注释掉即可，即不用加任何注释。

C .对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三 个斜杠(///)来说明注释掉代码的理由。

D .不要在视图模板中加入任何复杂的逻辑。

简单解析： P21【参考】：谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。 说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库已然保存了历史代码）

P23 【推荐】：不要在视图模板中加入任何复杂的逻辑。 说明：根据 MVC 理论，视图的职责是展示，不要抢模型和控制器的活。

P23 【推荐】：及时清理不再使用的代码段或配置信息。 说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。 正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。

A .分页查询，当统计的count为0时，应该直接返回，不要再执行分页查询语句。

B .iBATIS自带的queryForList(String statementName,int start,int size)分页接口有性能隐患，不允许使用。

C .定义明确的sql查询语句，通过传入参数start和size来实现分页逻辑。

D .可使用存储过程写分页逻辑，提高效率。

简单解析： P34【强制】：禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

【强制】代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句

P35 【强制】：iBATIS 自带的 queryForList(String statementName,int start,int size)不推荐使用。 说明：其实现方式是在数据库取到 statementName 对应的 SQL 语句的所有记录，再通过 subList 取start,size 的子集合。 正例：

A .订单详情页面。

B .类目管理后台。

C .店铺装修后台。

D .订单付款页面。

简单解析：P30 【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。 说明：防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容、修改他人的订单。

A .NULL=NULL的返回结果为true。

B .NULL与任何值的比较结果都为NULL。

C .NULL1的返回结果为true。

D .当某一列的值全是NULL时，sum(col)的返回结果为NULL。

简单解析：P34 【强制】使用 ISNULL()来判断是否为 NULL 值。 说明：NULL 与任何值的直接比较都为 NULL。 1） NULLNULL 的返回结果是 NULL，而不是 false。 2） NULL=NULL 的返回结果是 NULL，而不是 true。 3） NULL1 的返回结果是 NULL，而不是 true。

【强制】当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为 NULL，因此使用 sum()时需注意 NPE 问题。 正例：使用如下方式来避免 sum 的 NPE 问题：SELECT IFNULL(SUM(column), 0) FROM table;

A .向公司外部提供的http/api接口，推荐使用“错误码”方式返回异常或者错误信息。

B .对于应用内部的方法调用，推荐使用“抛出异常”的方式处理异常或者错误信息。

C .跨应用的RPC调用，推荐使用将“错误码”和“错误简短信息”封装成Result的方式进行返回。

D .对外提供的接口，一定要保证逻辑健壮性：尽量避免空指针等技术类异常；对于业务类异常要做好错误码或者异常信息的封装。

简单解析： P25【参考】对于公司外的 http/api 开放接口必须使用“错误码”；而应用内部推荐异常抛出；跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess()方法、“错误码”、“错误简短信息”。 说明：关于 RPC 方法返回方式使用 Result 方式的理由： 1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。 2）如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题 的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。

P25【推荐】防止 NPE，是程序员的基本修养，注意 NPE 产生的场景： 1） 返回类型为基本数据类型，return 包装数据类型的对象时，自动拆箱有可能产生 NPE。 反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。 2） 数据库的查询结果可能为 null。 3） 集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。 4） 远程调用返回对象时，一律要求进行空指针判断，防止 NPE。 5） 对于 Session 中获取的数据，建议进行 NPE 检查，避免空指针。 6） 级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。 正例：使用 JDK8 的 Optional 类来防止 NPE 问题。

A .类的序列化与serialVersionUID毫无关系。

B .如果完全不兼容升级，不需要修改serialVersionUID值。

C .POJO类的serialVersionUID不一致会编译出错。

D .POJO类的serialVersionUID不一致会抛出序列化运行时异常。

简单解析：P8 【强制】序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败；如果完全不兼容升级，避免反序列化混乱，那么请修改 serialVersionUID 值。 说明：注意 serialVersionUID 不一致会抛出序列化运行时异常。

A .在接口类中的方法和属性使用public修饰符。

B .对于Service类，内部的实现类加Impl的后缀与接口区别。例如：ProductServiceImpl实现ProductService接口。

C .对于Service类，基于SOA的理念，是以接口方式暴露服务。

D .尽量不在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，而且是整个应用的基础常量。

简单解析： P3【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。 正例：接口方法签名 void commit(); 接口基础常量 String COMPANY = “alibaba”; 反例：接口方法定义 public abstract void f(); 说明：JDK8 中接口允许有默认实现，那么这个 default 方法，是对所有实现类都有价值的默认实现。

P3 接口和实现类的命名有两套规则： 1）【强制】对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部的实现类用Impl 的后缀与接口区别。 正例：CacheServiceImpl 实现 CacheService 接口。 2） 【推荐】如果是形容能力的接口名称，取对应的形容词为接口名（通常是–able 的形容词）。 正例：AbstractTranslator 实现 Translatable 接口

A .在 foreach 循环里进行元素的 remove操作。

B .使用Iterator方式，如果有并发，需要对Iterator对象加锁。

C .Iterator进行元素的删除操作，绝对是线程安全的。

D .Java无法实现在遍历时，进行删除元素操作。

简单解析：P12 【强制】不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用Iterator 方式，如果并发操作，需要对 Iterator 对象加锁。 正例：

反例：

说明：以上代码的执行结果肯定会出乎大家的意料，那么试一下把“1”换成“2”，会是同样的结果吗？

A .所有的POJO类属性必须使用包装数据类型。

B .RPC方法的返回值和参数必须使用包装数据类型。

C .因为JAVA的自动装箱与拆箱机制，不需要根据场景来区分数据类型。

D .所有的局部变量推荐使用基本数据类型。

简单解析：P9 关于基本数据类型与包装数据类型的使用标准如下： 1） 【强制】所有的 POJO 类属性必须使用包装数据类型。 2） 【强制】RPC 方法的返回值和参数必须使用包装数据类型。 3） 【推荐】所有的局部变量使用基本数据类型。 说明：POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何 NPE 问题，或者入库检查，都由使用者来保证。

正例：数据库的查询结果可能是 null，因为自动拆箱，用基本数据类型接收有 NPE 风险。 反例：比如显示成交总额涨跌情况，即正负 x%，x 为基本数据类型，调用的 RPC 服务，调用不成功时，返回的是默认值，页面显示为 0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null 值，能够表示额外的信息，如：远程调用失败，异常退出。

A .对varchar类型的字段建立索引，必须指定索引长度。

B .对varchar类型的字段建立索引，不需要指定索引长度，这样索引区分度最好。

C .业务上具有唯一特性的字段（含组合字段），必须指定唯一索引。

D .建复合索引时，一般选择区分度高的字段放在最左列。

简单解析： P33【强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。 说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。

P33【推荐】建组合索引的时候，区分度最高的在最左边。 正例：如果 where a=? and b=? ，如果 a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即可。 说明：存在非等号和等号混合时，在建索引时，请把等号条件的列前置。如：where c>? and d=? 那么 即使 c 的区分度更高，也必须把 d 放在索引的最前列，即索引 idx_d_c。

A .版本号命名格式：主版本号.次版本号.修订号。

B .主版本号:产品方向改变，或者大规模API不兼容，或者架构不兼容升级。

C .次版本号:保持相对兼容性，增加主要功能特性，影响范围极小的API不兼容修改。

D .修订号:保持完全兼容性，修复BUG、新增次要功能特性等。

简单解析：P38 【强制】二方库版本号命名方式：主版本号.次版本号.修订号 1）主版本号：产品方向改变，或者大规模 API 不兼容，或者架构不兼容升级。 2） 次版本号：保持相对兼容性，增加主要功能特性，影响范围极小的 API 不兼容修改。 3） 修订号：保持完全兼容性，修复 BUG、新增次要功能特性等。 说明：注意起始版本号必须为：1.0.0，而不是 0.0.1，正式发布的类库必须先去中央仓库进行查证，使版 本号有延续性，正式版本号不允许覆盖升级。如当前版本：1.3.3，那么下一个合理的版本号：1.3.4 或 1.4.0 或 2.0.0

A .查询语句 WHERE a+1 = 5 可以利用a索引。

B .查询语句WHERE date_format(gmt_create, ‘%Y-%m-%d’) = '2016-11-11’无法利用gmt_create索引。

C .当 c 列类型为 char 时，查询语句 WHERE c = 5 无法利用c索引。

D .索引字段使用时不能进行函数运算。

简单解析：P33 【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。索引列上有函数运算，导致不走索引

A .异常信息应该包括两类信息：案发现场信息和异常堆栈信息。

B .日志文件推荐至少保存15天，因为有些异常具备以“周”为频次发生的特点。

C .避免重复打印日志，浪费磁盘空间，务必在log4j.xml中设置additivity=false。

D .错误日志和业务日志尽量分开存放。

简单解析： P26【强制】所有日志文件至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。网络运行状态、安全相关信息、系统监测、管理后台操作、用户敏感操作需要留存相关的网络日志不少于 6 个月。

【强制】避免重复打印日志，浪费磁盘空间，务必在 log4j.xml 中设置 additivity=false。 正例：

【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。 正例：logger.error(各类参数或者对象 toString() + “_” + e.getMessage(), e);

A .特殊注释标记，请注明标记人与标记时间。

B .待办事宜（TODO）:（ [标记人，标记时间，[预计处理时间]）

C .在注释中用FIXME标记某代码虽然实现了功能，但是实现的方法有待商榷，希望将来能改进

D .在注释中用FIXME标记某代码是错误的，而且不能工作，需要及时纠正的情况

简单解析：

P22【参考】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描，经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。 1） 待办事宜（TODO）:（标记人，标记时间，[预计处理时间]） 表示需要实现，但目前还未实现的功能。这实际上是一个 Javadoc 的标签，目前的 Javadoc 还没有实现，但已经被广泛使用。只能应用于类，接口和方法（因为它是一个 Javadoc 标签）。 2） 错误，不能工作（FIXME）:（标记人，标记时间，[预计处理时间]） 在注释中用 FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况。

A .主键查询优先于二级索引查询。

B .表连接有一定的代价，故表连接数量越少越好。

C .一般情况下，二级索引扫描优先于全表扫描。

D .可以使用通过索引避免排序代价。

简单解析： P33【推荐】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合 索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。

正例：where a=? and b=? order by c; 索引：a_b_c 反例：索引如果存在范围查询，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引 a_b 无 法排序

【推荐】SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts 最好。 说明： 1） consts 单表中最多只有一个匹配行（主键或者唯一索引）,在优化阶段即可读取到数据。 2） ref 指的是使用普通的索引（normal index）。 3） range 对索引进行范围检索。 反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range还低，与全表扫描是小巫见大巫。

A .若查询条件中不包含索引的最左列，则无法使用索引。

B .对于范围查询，只能利用索引的最左列。

C .对于order by A或group by A语句，在A上建立索引，可以避免排序。？

D .对于多列排序，需要所有所有列排序方向一致，才能利用索引。？

简单解析： P33 同上

A .抽象类命名使用Abstract或Base开头。

B .异常类命名使用Exception结尾。

C .测试类命名以它要测试的类的名称开始，以Test结尾。

D .如果使用到了设计模式，建议在类名中体现出具体模式。例如代理模式的类命名：LoginProxy；观察者模式命名：ResourceObserver。

简单解析： P1【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。

【推荐】如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。 说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。

A .绝对禁止左模糊。

B .绝对禁止全模糊。

C .绝对禁止右模糊。

D .全模糊或左模糊查询需求，优先使用搜索引擎。

简单解析： P33【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。 说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

A .所有的抽象方法（包括接口中的方法）必须要用javadoc注释。

B .所有的方法，包括私有方法，最好都增加注释，有总比没有强。

C .过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

D .我的命名和代码结构非常好，可以减少注释的内容。

简单解析： P21【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

A .继承java.lang.Error的类属于checked exception。

B .checked异常继承java.lang.Exception类。

C .unchecked异常继承java.lang.RuntimeException类。

D .NullPointerException , IllegalArgumentException属于unchecked exception。

简单解析： P21【推荐】定义时区分 unchecked / checked 异常，避免直接抛出 new RuntimeException()， 更不允许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定义过的自定义异常，如：DAOException / ServiceException 等

A .Map类型的实现类都同时实现了Iterator接口。

B .使用foreach进行遍历。

C .推荐使用keySet进行遍历。

D .推荐使用entrySet进行遍历。

简单解析： P13【推荐】使用 entrySet 遍历 Map 类集合 KV，而不是 keySet 方式进行遍历。 说明：keySet 其实是遍历了 2 次，一次是转为 Iterator 对象，另一次是从 hashMap 中取出 key 所对应 的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中，效率更高。如果是 JDK8，使用 Map.forEach 方法。

A .POJO类中的任何布尔类型的变量，都不要加is，因为部分框架解析时有可能会出现序列化错误。

B .包名统一使用单数形式，如：com.alibaba.mpp.util。

C .中括号是数组类型的一部分，数组定义如下：String[] args; 不要误写为String args[]；

D .Service/DAO层方法命名可以参考规约，例如：删除的方法推荐使用remove或delete做前缀。

简单解析： P1-2【强制】类型与中括号紧挨相连来表示数组。

正例：定义整形数组 int[] arrayDemo; 反例：在 main 参数中，使用 String args[]来定义。

【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。 正例：应用工具类包名为 com.alibaba.ai.util、类名为 MessageUtils（此规则参考 spring 的框架结构）

A .不允许出现任何魔法值（即未经预先定义的常量）直接出现在代码中。

B .魔法值是指程序中随意定义并赋值的变量值，如果代码编写者明白变量值意义是可以任意使用的，例如在代码中写if(status == 3) return error;符合规范。

C .如果变量值仅在一个范围内变化推荐用Enum类。

D .在程序中，一律禁止使用枚举类型。

简单解析： P4【强制】不允许任何魔法值（即未经预先定义的常量）直接出现在代码中。

【推荐】如果变量值仅在一个固定范围内变化用 enum 类型来定义。 说明：如果存在名称之外的延伸属性应使用 enum 类型，下面正例中的数字就是延伸信息，表示一年中的第几个季节。

A .(dependencies)的依赖会默认传递给子项目。

B .(dependencies)的依赖绝对不会传递给子项目。

C .在(dependencyManagement)中指定版本号。

D .避免在不同的子项目，