详解Java代码常见优化方案

首先,良好的编码规范非常重要。在 java 程序中,访问速度、资源紧张等问题的大部分原因,都是代码不规范造成的。

成都创新互联公司是一家专注于网站建设、成都网站制作与策划设计,独山子网站建设哪家好?成都创新互联公司做网站,专注于网站建设十年,网设计领域的专业建站公司;建站业务涵盖:独山子等地区。独山子做网站价格咨询:028-86922220

单例的使用场景

单例模式对于减少资源占用、提高访问速度等方面有很多好处,但并不是所有场景都适用于单例。

简单来说,单例主要适用于以下三个方面:

  1. 多线程场景,通过线程同步来控制资源的并发访问。
  2. 多线程场景,控制数据共享,让多个不相关的进程或线程之间实现通信(通过访问同一资源来控制)。
  3. 控制实例的产生,单例只实例化一次,以达到节约资源的目的;

不可随意使用静态变量

当某个对象被定义为 static 变量,那么 GC 通常是不会回收这个对象所占有的内存。

示例如下:

public class A {
  private static B b = new B();
}

此时静态变量 b 的生命周期与 A 类同步,即如果 A 类不卸载,b 对象会常驻内存,直到程序终止。

创建 Java 对象使用注意事项

根据业务使用场景,尽量避免在循环中 new 对象。

这是因为系统要花费时间来创建对象,而且还要花时间对这些对象进行管理和垃圾回收。所以在可以控制的范围内,尽量保证最大限度地重用对象,最好能用基本的数据类型或数组来替代对象。

final 修饰符使用注意事项

final 修饰符的类是不可派生的,即不可被继承。在 java 核心代码中,有很多 被 final 修饰的类,如 java.lang.String 类。

如果一个类是 final 的,则该类所有方法都是 final 的。java 编译器会寻找机会内联(inline)所有的 final 方法,这与具体的编译器实现有关。这样做能够使性能平均提高 50% 。

示例如下:

class A {
  public void setSize (int size) {
    this.size = size;
  }
  private int size;
}
// setSize 方法变为 final ,性能更好
class A {
  final public void setSize (int size) {
    this.size = size;
  }
  private int size;
}

让访问实例变量的 getter/setter 方法变成 final:简单的 getter/setter 方法应该被置成 final ,这会告诉编译器此方法不会被重载,可以变成 ”inlined” 。

局部变量使用规范

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Stack)中,速度较快;其他变量,如静态变量、实例变量等,都在堆(Heap)中创建,速度较慢。

处理好包装类型和基本类型的使用场所

基本类型:byte,short,int,long,float,double,char,boolean
对应包装类型:Byte,Short,Int,Long,Float,Double,Character,Boolean

基本类型和包装类型在使用过程中可以相互转换,但它们所产生的内存区域是完全不同的。基本类型的产生和处理都在栈中处理,包装类型是引用类型,其对象是在堆中产生实例。

在集合类对象,有对象方面需要的处理使用包装类型合适,其他情况的处理提倡使用基本类型。

使用基本数据类型代替对象

示例如下:

String s1 = "hello";

这种方式会创建一个 “hello” 字符串,而且 JVM 的字符缓存池会缓存这个字符串。

String s2 = new String("hello");

这种方式除了创建字符串外,s2 所引用的 String 对象底层包含一个 char[] 数组,其中依次存放了 h,e,l,l,o 。

synchronized 使用规范

实现同步需要很大的系统开销作为代价的,甚至可能造成死锁。所以尽量避免无谓的同步控制。

synchronize 方法被调用时会直接把当前对象锁住,在该方法执行完之前其他线程无法调用当前对象的其它方法。比较灵活的用法是使用代码块同步代替在方法中同步。

finalize使用规范

不要将资源清理放在 finalize 方法中完成,这种方法也很少使用。

由于 GC 的工作量很大,尤其是回收 Young 代内存时,大都会引起应用程序暂停。如果选择使用 finalize 方法进行资源清理,会导致 GC 负担加大,程序运行效率变差。

不需要线程同步,应尽量使用 HashMap 、ArrayList

HashTable 、Vector 等使用了同步机制,导致降低。

HashMap 使用规范

创建一个比较大的 hashMap 时,应该使用带有参数的构造函数创建对象。

示例如下:

public HashMap(int initialCapacity, float loadFactor);

hash 扩容是一件很耗费性能的事,默认构造函数创建的对象的 initialCapacity 只有 16,loadFactor 是 0.75 ,最好准确的估计所需要的最佳大小。同样对于 Hashtable ,Vectors 也是如此。

减少对变量的重复计算

for (int i = 0; i < list.size(); i++) {...}
// 应该改为
for (int i=0, l=list.size(); i < l; i++) {...}

避免不必要的创建对象

A a = new A();
if (i == 1) {
  list.add(a);
}
// 应该改为
if (i == 1) {
  A a = new A();
  list.add(a);
}

finally 使用规范

在 try-catch 里,使用到的资源要能够被释放,以避免资源泄漏,这最好在 finally 块中去做。无论程序执行是否有异常,finally 里的代码总是会执行的,这样可以确保资源的正确关闭。

StringBuffer使用规范

StringBuffer 的无参构造函数会创建一个默认 16 的字符数组。在使用过程中,如果数组长度超出 16 ,就要重新分配内存,创建一个容量更大的数组,并将原先的数组复制过来,再丢弃旧的数组。

在多数情况下,可以在创建 StringBuffer 的时候指定大小,避免了在容量不够的时候自动增长,以提高性能。

StringBuffer sb= new StringBuffer(int capacity);

显式释放空间让 gc 回收对象

多数情况下,方法内部的局部引用变量所引用的对象会随着方法结束而变成垃圾被回收。因此在程序中无需将局部引用变量显式设为 null 。

示例如下:

void gcTest1() {
  Object obj = new Object();
  ……
  obj = null;
}

随着方法 gcTest1() 的执行完成,程序中局部引用变量 obj 的作用域就结束了,这时没有必要执行 obj = null 。

反例如下:

void gcTest2(){
  Object obj = new Object();
  ……
  obj = null;
  //耗时,耗内存操作
  ……
}

此时需要尽早释放不再使用的空间,执行 obj = null 显式释放局部引用变量 obj 。

二维数组使用规范

二维数据占用的内存空间大概是一维数组的 10 倍以上。

split 使用场景

尽量避免使用 split 。split 使用正则表达式,效率比较低,如果是频繁的调用将会耗费大量资源。

如果确实需要频繁的调用 split ,使用 apache 的 StringUtils.split(string,char) 较好 ,可以缓存结果。

ArrayList 和 LinkedList 使用规范

对于线性表及链表,随机查询的操作ArrayList 优于 LinkedList ,LinkedList 需要移动指针。增加删除的操作 LinkedList 优于 ArrayList ,ArrayList 需要移动数据。

System.arraycopy() 使用规范

尽量使用 System.arraycopy() 复制数组,它要比通过循环来复制数组快的多。

缓存对象

将经常使用的对象进行缓存时,可以使用数组或者 HashMap 等容器来缓存。这种方式需要自己管理这些容器,可能导致系统占用过多的缓存,性能下降。

也可以使用一些第三方的开源工具,如 EhCache 、Oscache 进行缓存,他们基本都实现了 FIFO/FLU 等缓存算法。

尽量避免非常大的内存分配

有的问题不是由于堆内存不够造成的,而是因为内存分配失败造成的。(gc会进行内存碎片整理)

如果分配的内存块都必须是连续的,随着堆越来越满,找到较大的连续块会越来越困难。

try/catch 使用场景

不要在循环中使用 try/catch 语句,应该把 try/catch 放在循环最外层。

以上所述是小编给大家介绍的Java代码常见优化方案详解整合,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对创新互联网站的支持!


当前标题:详解Java代码常见优化方案
文章起源:http://azwzsj.com/article/ggdhse.html