上一篇Java编程规约一

1、【强制】避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。这点很好理解，你都设置了静态变量、静态方法了，还要通过对象访问干嘛，除了增加编译器的压力外，然并卵。

2、【强制】所有的覆写方法，必须加@Override注解。 说明：getObject()与get0bject()的问题。一个是字母的O，一个是数字的0，加@Override可以准确判断是否覆盖成功。另外，如果在抽象类中对方法签名进行修改，其实现类会马上编译报错。这一点确实方便，特别是代码非常多的时候，修改了一个地方后，其他地方就忘记改了，如果编译器能自动提醒你，无疑释放了你的脑空间。

3、【强制】相同参数类型，相同业务含义，才可以使用Java的可变参数，避免使用Object。
说明：可变参数必须放置在参数列表的最后。（提倡同学们尽量不用可变参数编程）
正例：，一般通过构造数组或者重载进行实现吧，虽然这种方式简化了代码，但当你的代码转交给你的伙伴时，若你还没有进行说明，可能会带来阅读上的困难， 另外，可维护性也不是很好。

4、【强制】外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响。接口过时（out了）必须加@Deprecated注解，并清晰地说明采用的新接口或者新服务是什么。（意思是说此方法已过时，过时的原因就是有新的API的类替代了次方法。这个被划去的方法仍然是可以正常使用的，就是一个提示而已。）

5、【强制】不能使用过时的类或方法。 说明：java.net.URLDecoder 中的方法decode(String encodeStr) 这个方法已经过时，应该使用双参数decode(String source, String encode)。接口提供方既然明确是过时接口，那么有义务同时提供新的接口；作为调用方来说，有义务去考证过时方法的新实现是什么。

6、【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。
正例：“test”.equals(object); 反例：object.equals(“test”);
说明：推荐使用java.util.Objects#equals（JDK7引入的工具类，其中，它帮我们实现了非空判断。另外，我们在编写时，也需要养成一个习惯，即常量放外边，变量放equals里边，如果都是变量，应该加上非空判断，这样，才不容易报空指针异常）

7、【强制】所有的相同类型的包装类对象之间值的比较，全部使用equals方法比较。 说明：对于Integer var = ? 在-128至127范围内的赋值，Integer对象是在IntegerCache.cache产生，会复用已有对象，这个区间内的Integer值可以直接使用==进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用equals方法进行判断。（这个对于初学者确实容易混乱，Integer是一个包装类，它实例化了-128到127之间的数（对象），然后放置在常量池中，如果在这个范围内，不通过new新建一个数，不管是用等号比较还是equals，总是会返回true。）

8、关于基本数据类型与包装数据类型的使用标准如下：
1） 【强制】所有的POJO类属性必须使用包装数据类型。
2） 【强制】RPC方法的返回值和参数必须使用包装数据类型。
3） 【推荐】所有的局部变量使用基本数据类型。

说明：POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。（NPE，NullPointerException，编程语言中的空指针异常。）

正例：数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。

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

9、【强制】定义DO/DTO/VO等POJO类时，不要设定任何属性默认值。

反例：POJO类的gmtCreate默认值为new Date()，但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。

10、【强制】序列化类新增属性时，请不要修改serialVersionUID字段，避免反序列失败；如果完全不兼容升级，避免反序列化混乱，那么请修改serialVersionUID值。

说明：注意serialVersionUID不一致会抛出序列化运行时异常。（Java的序列化机制是通过判断类serialVersionUID 来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常，即是InvalidCastException。）

11、【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中。

12、【强制】POJO类必须写toString方法。使用IDE中的工具：source> generate toString时，如果继承了另一个POJO类，注意在前面加一下super.toString。
说明：在方法执行抛出异常时，可以直接调用POJO的toString()方法打印其属性值，便于排查问题。

13、【强制】禁止在 POJO类中，同时存在对应属性 xxx的 isXxx()和 getXxx()方法。 说明： 框架在调用属性 xxx 的提取方法时，并不能确定哪个一是被优先调用到。（这点和我上一篇的第八点所说的原因类似）

14、【推荐】使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛IndexOutOfBoundsException的风险。
说明：

15、【推荐】当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读，此条规则优先于第16条规则。

16、【推荐】 类内方法定义的顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter方法。

说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类关心，也可能是“模板设计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个黑盒实现；因为承载的信息价值较低，所有Service和DAO的getter/setter方法放在类体最后。

17、【推荐】setter方法中，参数名称与类成员变量名称一致，this.成员名 = 参数名。在getter/setter方法中，不要增加业务逻辑，增加排查问题的难度。 反例：

18、【推荐】循环体内，字符串的连接方式，使用StringBuilder的append方法进行扩展。
说明：下例中，反编译出的字节码文件显示每次循环都会new出一个StringBuilder对象，然后进行append操作，最后通过toString方法返回String对象，造成内存资源浪费。
反例：

19、【推荐】final可以声明类、成员变量、方法、以及本地变量，下列情况使用final关键字：
1） 不允许被继承的类，如：String类。
2） 不允许修改引用的域对象。
3） 不允许被重写的方法，如：POJO类的setter方法。
4） 不允许运行过程中重新赋值的局部变量。 5） 避免上下文重复使用一个变量，使用final描述可以强制重新定义一个变量，方便更好地进行重构。

20、【推荐】慎用Object的clone方法来拷贝对象。
说明：对象的clone方法默认是浅拷贝，若想实现深拷贝需要重写clone方法实现域对象的深度遍历式拷贝。（这个可以自己体会体会，默认是浅复制，即拷贝对象时仅仅拷贝对象本身，包括对象中的基本变量，而不拷贝对象包含的引用指向的对象。而深复制不仅拷贝对象本身，而且拷贝对象包含的引用指向的所有对象。如下：）

很明显，直接调用object中的clone，虽然实现了复制，但是如果像TestStudent类那样，包含教师类的引用，这个引用经过复制后，它的内存地址是一样的，所以造成了上面的情况，修改了学生二stu2的姓名，年龄，和老师的职称后，对于学生一stu1而言，姓名，年龄不影响，但老师职称变了。正确方法如下：
在TestTeacherClone类中，添加如下代码，记得实现Cloneable接口，不然会报错CloneNotSupported：

修改TestStudentClone类代码：

重新打印结果

21、【推荐】类成员与方法访问控制从严：
1） 如果不允许外部直接通过new来创建对象，那么构造方法必须是private。
2） 工具类不允许有public或default构造方法。
3） 类非static成员变量并且与子类共享，必须是protected。
4） 类非static成员变量并且仅在本类使用，必须是private。
5） 类static成员变量如果仅在本类使用，必须是private。
6） 若是static成员变量，考虑是否为final。
7） 类成员方法只供类内部调用，必须是private。
8） 类成员方法只对继承类公开，那么限制为protected。
说明：任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。
思考：如果是一个private的方法，想删除就删除，可是一个public的service成员方法或成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视线内，变量作用域太大，无限制的到处跑，那么你会担心的。这里，个人觉得，也方便代码的调试，在出错时，快速缩小排查范围

1、【强制】关于hashCode和equals的处理，遵循如下规则：
1） 只要重写equals，就必须重写hashCode。
2） 因为Set存储的是不重复的对象，依据hashCode和equals进行判断，所以Set存储的对象必须重写这两个方法。
3） 如果自定义对象作为Map的键，那么必须重写hashCode和equals。
说明：String重写了hashCode和equals方法，所以我们可以非常愉快地使用String对象作为key来使用。

2、【强制】 ArrayList的subList结果不可强转成ArrayList，否则会抛出ClassCastException异常，即
。
说明：subList 返回的是 ArrayList 的内部类 SubList，并不是 ArrayList，而是ArrayList 的一个视图，对于SubList子列表的所有操作最终会反映到原列表上。这个查看源码可知，类似于SQL中的视图，它返回ArrayList中的一部分内容，通过指定起始坐标和结束坐标

3、【强制】在subList场景中，高度注意对原集合元素的增加或删除，均会导致子列表的遍历、增加、删除产生ConcurrentModificationException 异常。这个注意非常容易发生的，特别实在多线程的情况下，如下：

报错：

查看源码，访问size()必须访问checkForComodification()方法，它会判断modCount是否相等：


解决办法：


另外，在通过集合遍历集合时，对集合的增删等操作，也会容易引起该错误，错误本质相似，可类比解决

4、【强制】使用集合转数组的方法，必须使用集合的toArray(T[] array)，传入的是类型完全一样的数组，大小就是list.size()。

说明：使用toArray带参方法，入参分配的数组空间不够大时，toArray方法内部将重新分配内存空间，并返回新数组地址；如果数组元素个数大于实际所需，下标为[ list.size() ]的数组元素将被置为null，其它数组元素保持原值，因此最好将方法入参数组大小定义与集合元素个数一致。
正例：

反例：直接使用toArray无参方法存在问题，此方法返回值只能是Object[]类，若强转其它类型数组将出现ClassCastException错误。

5、【强制】使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，它的add/remove/clear方法会抛出UnsupportedOperationException异常。 说明：asList的返回对象是一个Arrays内部类，并没有实现集合的修改方法。Arrays.asList体现的是适配器模式，只是转换接口，后台的数据仍是数组。

第一种情况：list.add(“yangguanbao”); 运行时异常。
第二种情况：str[0] = “gujin”; 那么list.get(0)也会随之修改。

6、【强制】泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用add方法，而<? super T>不能使用get方法，作为接口调用赋值时易出错。 说明：扩展说一下PECS(Producer Extends Consumer Super)原则：第一、频繁往外读取内容的，适合用<? extends T>。第二、经常往里插入的，适合用<? super T>。

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

反例：

说明：以上代码的执行结果肯定会出乎大家的意料，那么试一下把“1”换成“2”，会是同样的结果吗？
这里顺便给出答案吧，在删除1时时没问题，但删除2时报错ConcurrentModificationException，跟第三点类似，查看源码可得：

删除元素时，会调用rangeCheck()方法进行size和坐标的判断，所以删除第一个是安全的，但删除第二个时则会报错，正确解决方法可以改用迭代器进行操作。

正确解决办法：

8、【强制】 在JDK7版本及以上，Comparator实现类要满足如下三个条件，不然Arrays.sort，Collections.sort会报IllegalArgumentException异常。
说明：三个条件如下 ：
1） x，y的比较结果和y，x的比较结果相反。
2） x>y，y>z，则x>z。
3） x=y，则x，z比较结果和y，z比较结果相同。

** 反例：下例中没有处理相等的情况，实际使用中可能会出现异常：**

9、【推荐】集合泛型定义时，在JDK7及以上，使用diamond语法或全省略。
说明：菱形泛型，即diamond，直接使用<>来指代前边已经指定的类型。
正例：

10、【推荐】集合初始化时，指定集合初始值大小。
说明：HashMap使用HashMap(int initialCapacity) 初始化。
正例：initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意 负载因子（即loader factor）默认为 0.75，如果 暂时无法 确定 初始值大小，请设置为 16（即默认值）。

反例： HashMap需要 放置 1024个元素， 由于 没有设置容量 初始大小，随着元素不断增加容 量 7次被迫扩大， resize需要重建 hash表，严重影响性能。

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

正例：values()返回的是V值集合，是一个list集合对象；keySet()返回的是K值集合，是一个Set集合对象；entrySet()返回的是K-V值组合集合。

12、【推荐】高度注意Map类集合K/V能不能存储null值的情况，如下表格：

13、【参考】合理利用好集合的有序性(sort)和稳定性(order)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。

说明：有序性是指遍历的结果是按某种比较规则依次排列的。稳定性指集合每次遍历的元素次序是一定的。如：ArrayList是order/unsort；HashMap是unorder/unsort；TreeSet是order/sort。

14、【参考】利用Set元素唯一的特性，可以快速对一个集合进行去重操作，避免使用List的contains方法进行遍历、对比、去重操作。

1、【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。
说明：资源驱动类、工具类、单例工厂类都需要注意。

2、 【强制】创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。
正例：

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

4、【强制】线程池不允许使用 Executors去创建，而是通过 ThreadPoolExecutor的方式，这样的处理方式，让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

说明： Executors返回的线程池对象的弊端 如下 ：

5、【强制】SimpleDateFormat 是线程不安全的类，一般不要定义为static变量，如果定义为static，必须加锁，或者使用Date Utils工具类。

正例：注意线程安全，使用DateUtils。亦推荐如下处理：

说明：如果是JDK8的应用，可以使用Instant代替Date，LocalDateTime代替Calendar，DateTimeFormatter代替SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。

6、【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。

说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC（前面所说的远程过程调用）方法。

7、【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。

说明：线程一需要对表A、B、C依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是A、B、C，否则可能出现死锁。

8、【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version（版本号）作为更新依据。

说明：如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于3次。

9、【强制】多线程并行处理定时任务时，Timer运行多个Timetask时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用ScheduledExecutorService则没有这个问题。

10、【推荐】使用CountDownLatch进行异步转同步操作，每个线程退出前必须调用countDown方法，线程执行代码注意catch异常，确保countDown方法被执行到，避免主线程无法执行至await方法，直到超时才返回结果。

说明：注意，子线程抛出异常堆栈，不能在主线程try-catch到。

11、【推荐】避免Random实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一seed 导致的性能下降。
说明：Random实例包括java.util.Random 的实例或者 Math.random()的方式。 正例：在JDK7之后，可以直接使用API ThreadLocalRandom，而在 JDK7之前，需要编码保证每个线程持有一个实例。

12、【推荐】在并发场景下，通过双重检查锁（double-checked locking）实现延迟初始化的优化问题隐患(可参考 The “Double-Checked Locking is Broken” Declaration)，推荐解决方案中较为简单一种（适用于JDK5及以上版本），将目标属性声明为 volatile型。 反例：

13、【参考】volatile解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，但是如果多写，同样无法解决线程安全问题。如果是count++操作，使用如下类实现：

如果是JDK8，推荐使用LongAdder对象，比AtomicLong性能更好（减少乐观锁的重试次数）。

14、【参考】 HashMap在容量不够进行resize时由于高并发可能出现死链，导致CPU飙升，在开发过程中可以使用其它数据结构或加锁来规避此风险。

15、【参考】ThreadLocal无法解决共享对象的更新问题，ThreadLocal对象建议使用static修饰。这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。

1、【强制】在高并发场景中，避免使用 ”等于 ”判断作为中或退出的条件。 判断作为中或退出的条件。

说明： 如果并发控制没有处理好，容易产生等值判断被 如果并发控制没有处理好，容易产生等值判断被 “击穿 ”的情况，使用大于或小区间 判断条件来代替。

反例： 判断剩余奖品数量等于 0时，终止发放奖品，但因为并处理错误导致数量瞬间变成了负数， 这样，活动将无法终止。

1、【强制】在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。

说明：不要在方法体内定义：Pattern pattern = Pattern.compile(“规则”);

2、【强制】velocity（一个基于java的模板引擎）调用POJO类的属性时，建议直接使用属性名取值即可，模板引擎会自动按规范调用POJO的getXxx()，如果是boolean基本数据类型变量（boolean命名不需要加is前缀），会自动调用isXxx()方法。

说明：注意如果是Boolean包装类对象，优先调用getXxx()的方法。

3、【强制】后台输送给页面的变量必须加——中间的感叹号。 说明：如果var等于null或者不存在，那么${var}会直接显示在页面上。（这个常用JSP开发的道友肯定很熟悉）

4、【强制】注意 Math.random() 这个方法返回是double类型，注意取值的范围 0≤x<1（能够取到零值，注意除零异常），如果想获取整数类型的随机数，不要将x放大10的若干倍然后取整，直接使用Random对象的nextInt或者nextLong方法。

5、【强制】获取当前毫秒数System.currentTimeMillis(); 而不是new Date().getTime(); 说明：如果想获取更加精确的纳秒级时间值，使用System.nanoTime()的方式。在JDK8中，针对统计时间等场景，推荐使用Instant类。

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

7、【推荐】任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存。

8、【推荐】及时清理不再使用的代码段或配置信息。

说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。

    以上就是本篇文章【Java编程规约二】的全部内容了，欢迎阅览 ！ 文章地址：http://lianchengexpo.xrbh.cn/quote/9552.html 
     行业      资讯      企业新闻      行情      企业黄页      同类资讯      网站地图      返回首页 迅博思语资讯移动站 http://lianchengexpo.xrbh.cn/mobile/ , 查看更多