标签:
1. 对于明确不需要派生的类,添加final修饰符,此时该类的所有方法都是final的。Java编译器会寻找机会内联(inline)所有的final方法。(能使性能提升50%)
2. 尽量重用对象,避免生成过多的对象。对于String的连接,用StringBuffer代替。
3. 尽量少用全局变量如static等(heap中创建,慢),多用局部变量(Stack中创建,快)。
4. 不要重复初始化变量。默认情况下,调用类的构造函数时, Java会把变量初始化成确定的值:所有的对象被设置成null,整数变量(byte、short、int、long)设置成0,float和 double变量设置成0.0,逻辑值设置成false。当一个类从另一个类派生时,这一点尤其应该注意,因为用new关键词创建一个对象时,构造函数链中的所有构造函数都会被自动调用。即
class test{
private Object obj; //不需要写成 private Object obj=null;
}
5. 在java+Oracle的应用系统开发中,java中内嵌的SQL语言应尽量使用大写形式,以减少Oracle解析器的解析负担。
6. java编程过程中,进行数据库连接,I/O流操作,在使用完毕后,及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销。
7. 过分的创建对象会消耗系统的大量内存,严重时,会导致内存泄漏,因此,保证过期的对象的及时回收具有重要意义。
JVM的GC并非十分智能,因此建议在对象使用完毕后,手动设置成null。
8. 在使用同步机制时,尽量使用同步方法代替代码同步快。
9. 尽量减少对变量的重复计算。
例如:
for(int i=0; i<list.size(); i++)
应替换为:
for(int i=0, int len=list.size(); i< len; i++)
10. 需要时才创建变量或者对象。
例如:
String str=”hello”;
if(i==1){
list.add(str);
}
应替换为
if(i==1){
String str=”hello”;
list.add(str);
}
11. 慎用异常
异常对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为fillInStackTrace()的本地(Native)方法,fillInStackTrace()方法检查堆栈,收集调用跟踪信息。只要有异常被抛出,VM就必须调整调用堆栈,因为在处理过程中创建了一个新的对象。
异常只能用于错误处理,不应该用来控制程序流程。
12. 不要在循环中使用Try/Catch语句,若需要,应该放在最外层。
13. 若一个类实现了Cloneable,调用clone()方法创建类的实例。因为用new创建时,构造函数链中的所有构造函数都会被自动调用。
14. 乘法和除法
考虑下面的代码:
for (val = 0; val < 100000; val +=5) {
alterX = val * 8; myResult = val * 2;
}
用移位操作替代乘法操作可以极大地提高性能。下面是修改后的代 码:
for (val = 0; val < 100000; val += 5) {
alterX = val << 3; myResult = val << 1;
}
修改后的代码不再做乘以8的操作,而是改用等价的左移3位操作,每左移1位相当于乘以2。相应地,右移1位操作相当于除以2。值得一提的是,虽然移位操作速度快,但可能使代码比较难于理解,所以最好加上一些注释。
15. 尽量使用HashMap和ArrayList;除非必要,否则不推荐使用HashTable和Vector,后者由于同步机制导致了性能的开销。
16. 知道长度的情况下尽量使用定长数组array。
17. 当复制大量数据时,使用System.arraycopy()命令。
常用的:
1.优化循环。通过重新组织重复的子表达式来提高循环体的运行性能。
2减少使用对象的数量来提高运行性能。
3.缩减网络传输数据来缩短等待时间。
其他:
1.采用对象池技术,提高对象的利用效率。
性能的损耗主要源于创建和释放对象,因此要避免对象的创建和释放。采用对象池技术,预先定义一个对象池,预先创建一组待使用的对象:
Enemy[5] enemy=new Enemy[5];
for(int i=0;i<5;i++){
enemy[i]=new Enemy();
}
增加标志如used和reset标识Enemy的状态。需要创建对象时从对象池中获取 一个未被使用的对象并用reset方法初始化;需要释放时只需修改标志位以供下次使用即可。详细请参加—Java对象池技术:http://www.cnblogs.com/devinzhang/archive/2012/01/05/2313406.html
2.尽可能使用基本数据类型代替对象
例如用二维数组代替一个写简单的对象。
3.优化算法
比如对于默写不要求很精细的场景和算法,用简单的算法模拟。
4.其他优化
a.如提取字符串时,试着返回子串而不是创建一个副本。
b.尽量的少创建短期的临时对象。
c.能用库函数的就不要自己创建(库函数是优化好的)
d.Map map=new HashMap();
HashMap map=new HashMap(); //这个性能更高,重构代码
e.增强型for循环和Iterable使用时,多了一个对象的创建,慎用。
f.避免enum类型。
g.嵌入式开发时注意浮点的运用,尽量不用。(处理器是否支持浮点)
h.图片资源压缩、多张图片集中到一张图片上(比单独的和小很多,省去了每张的头文件、结束文件等数据块,合并了调色板)
文章转自:http://www.cnblogs.com/devinzhang/archive/2012/01/04/2312218.html 和 http://www.cnblogs.com/devinzhang/archive/2012/01/06/2314118.html
1. android内存泄露概念
不少人认为JAVA程序,因为有垃圾回收机制,应该没有内存泄露。其实如果我们一个程序中,已经不再使用某个对象,但是因为仍然有引用指向它,垃圾回收器就无法回收它,当然该对象占用的内存就无法被使用,这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生,最后就没内存可用了。当然java的,内存泄漏和C/C++是不一样的。如果java程序完全结束后,它所有的对象就都不可达了,系统就可以对他们进行垃圾回收,它的内存泄露仅仅限于它本身,而不会影响整个系统的。C/C++的内存泄露就比较糟糕了,它的内存泄露是系统级,即使该C/C++程序退出,它的泄露的内存也无法被系统回收,永远不可用了,除非重启机器。
Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行,Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行,也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限,如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限,则会被系统视为内存泄漏,从而被kill掉,这使得仅仅自己的进程被kill掉,而不会影响其他进程(如果是system_process等系统进程出问题的话,则会引起系统重启)。
内存泄露示例:
/*此时,所有的Object对象都没有被释放,因为变量v引用这些对象。实际上这些对象已经是无用的,但还被引用,GC就无能为力了(事实上GC认为它还有用),这一点是导致内存泄漏最重要的原因。*/
Vector v = new Vector(10);
for (int i = 1; i < 100; i++) {
Object o = new Object();
v.add(o);
o = null;
}
循环申请Object对象,并将所申请的对象放入一个Vector中,如果仅仅释放对象本身,但因为Vector仍然引用该对象,所以这个对象对GC来说是不可回收的。因此,如果对象加入到Vector后,还必须从Vector中删除,最简单的方法就是将Vector对象设置为null。
总的来说,内存管理中的内存泄漏产生的主要原因:保留下来却永远不再使用的对象引用。
2.引起内存泄露的情况
1)资源对象没关闭造成的内存泄露
资源性对象比如(Cursor,File文件等)往往都用了一些缓冲,我们在不使用的时候,应该及时关闭它们,以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内,还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们,往往会造成内存泄露。因为有些资源性对象,比如SQLiteCursor(在析构函数finalize(),如果我们没有关闭它,它自己会调close()关闭),如果我们没有关闭它,系统在回收它时也会关闭它,但是这样的效率太低了。因此对于资源性对象在不使用的时候,应该调用它的close()函数,将其关闭掉,然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。
程序中经常会进行查询数据库的操作,但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小,对内存的消耗不容易被发现,只有在常时间大量操作的情况下才会复现内存问题,这样就会给以后的测试和问题排查带来困难和风险。
2)一些不良代码成内存压力
有些代码并不造成内存泄露,但是它们,或是对没使用的内存没进行有效及时的释放,或是没有有效的利用已有的对象而是频繁的申请新内存,对内存的回收和分配造成很大影响的,容易迫使虚拟机不得不给该应用进程分配更多的内存,造成不必要的内存开支。
a.Bitmap没调用recycle()
Bitmap对象在不使用时,我们应该先调用recycle()释放内存,然后才它设置为null。
虽然recycle()从源码上看,调用它应该能立即释放Bitmap的主要内存,但是测试结果显示它并没能立即释放内存。但是我它应该还是能大大的加速Bitmap的主要内存的释放。
b.构造Adapter时,没有使用缓存的convertView
以构造ListView的BaseAdapter为例,在BaseAdapter中提共了方法:
public View getView(int position, View convertView, ViewGroup parent)
来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象,同时ListView会将这些view对象缓存起来。当向上滚动ListView时,原先位于最上面的list item的view对象会被回收,然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的,getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。
由此可以看出,如果我们不去使用convertView,而是每次都在getView()中重新实例化一个View对象的话,即浪费时间,也造成内存垃圾,给垃圾回收增加压力,如果垃圾回收来不及的话,虚拟机将不得不给该应用进程分配更多的内存,造成不必要的内存开支。
layout.xml
<?xml version="1.0" encoding="utf-8" ?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="60dip">
<ImageView android:id="@+id/icon" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentLeft="true" android:paddingLeft="9px" />
<TextView android:id="@+id/text" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_toRightOf="@id/icon" android:textAppearance="?android:attr/textAppearanceMedium" android:paddingLeft="9px" />
</RelativeLayout>
能引起内存泄露的代码: BadAdapter.java
public class BadAdapter extends BaseAdapter {
......
@Override
public View getView(int position, View convertView, ViewGroup parent) {
Log.d("MyAdapter", "Position:" + position + "---"
+ String.valueOf(System.currentTimeMillis()));
final LayoutInflater inflater = (LayoutInflater) mContext
.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View v = inflater.inflate(R.layout.list_item_icon_text, null);
((ImageView) v.findViewById(R.id.icon)).setImageResource(R.drawable.icon);
((TextView) v.findViewById(R.id.text)).setText(mData[position]);
return v;
}
}
修正优化示例代码示例代码:GoodAdapter.java
public class GoodAdapter extends BaseAdapter {
......
@Override
public View getView(int position, View convertView, ViewGroup parent) {
Log.d("MyAdapter", "Position:" + position + "---"
+ String.valueOf(System.currentTimeMillis()));
ViewHolder holder;
if (convertView == null) {
final LayoutInflater inflater = (LayoutInflater) mContext
.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
convertView = inflater.inflate(R.layout.list_item_icon_text, null);
holder = new ViewHolder();
holder.icon = (ImageView) convertView.findViewById(R.id.icon);
holder.text = (TextView) convertView.findViewById(R.id.text);
convertView.setTag(holder);
} else {
holder = (ViewHolder) convertView.getTag();
}
holder.icon.setImageResource(R.drawable.icon);
holder.text.setText(mData[position]);
return convertView;
}
static class ViewHolder {
ImageView icon;
TextView text;
}
}
MainActivity.java
public class MainActivity extends ListActivity {
private BadAdapter/GoodAdapter mAdapter;
private String[] mArrData;
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mArrData = new String[1000];
for (int i = 0; i < 1000; i++) {
mArrData[i] = "Google IO Adapter";
}
mAdapter = new BadAdapter/GoodAdapter(this, mArrData);
setListAdapter(mAdapter);
}
}
3)ThreadLocal使用不当
如果我们粗暴的把ThreadLocal设置null,而不调用remove()方法或set(null),那么就可能造成ThreadLocal绑定的对象长期也能被回收,因而产出内存泄露。
标签:
原文地址:http://www.cnblogs.com/hnfxs/p/5772505.html