打字猴:1.700442418e+09
1700442418
1700442419 (1)声明友好类和包内访问常量
1700442420
1700442421 这个比较简单,而且很实用,比如一个包中有很多内部访问的类或常量,就可以统一放到package-info类中,这样很方便,而且便于集中管理,可以减少友好类到处游走的情况,代码如下:
1700442422
1700442423 //这里是包类,声明一个包使用的公共类
1700442424
1700442425 class PkgClass{
1700442426
1700442427 public void test(){}
1700442428
1700442429 }
1700442430
1700442431 //包常量,只允许包内访问
1700442432
1700442433 class PkgConst{
1700442434
1700442435 static final String PACAKGE_CONST=“ABC”;
1700442436
1700442437 }
1700442438
1700442439 注意以上代码是存放在package-info.java中的,虽然它没有编写package-info的实现,但是package-info.class类文件还是会生成。通过这样的定义,我们把一个包需要的类和常量都放置在本包下,在语义上和习惯上都能让程序员更适应。
1700442440
1700442441 (2)为在包上标注注解提供便利
1700442442
1700442443 比如我们要写一个注解(Annotation),查看一个包下的所有对象,只要把注解标注到package-info文件中即可,而且在很多开源项目也采用了此方法,比如Struts2的@namespace、Hibernate的@FilterDef等。
1700442444
1700442445 (3)提供包的整体注释说明
1700442446
1700442447 如果是分包开发,也就是说一个包实现了一个业务逻辑或功能点或模块或组件,则该包需要有一个很好的说明文档,说明这个包是做什么用的,版本变迁历史,与其他包的逻辑关系等,package-info文件的作用在此就发挥出来了,这些都可以直接定义到此文件中,通过javadoc生成文档时,会把这些说明作为包文档的首页,让读者更容易对该包有一个整体的认识。当然在这点上它与package.htm的作用是相同的,不过package-info可以在代码中维护文档的完整性,并且可以实现代码与文档的同步更新。
1700442448
1700442449 解释了这么多,总结成一句话:在需要用到包的地方,就可以考虑一下package-info这个特殊类,也许能起到事半功倍的作用。
1700442450
1700442451
1700442452
1700442453
1700442454 编写高质量代码:改善Java程序的151个建议 [:1700438120]
1700442455 编写高质量代码:改善Java程序的151个建议 建议51:不要主动进行垃圾回收
1700442456
1700442457 很久很久以前,在Java 1.1的年代里,我们经常会看到System.gc这样的调用—主动对垃圾进行回收。不过,在Java知识深入人心后,这样的代码就逐渐销声匿迹了—这是好现象,因为主动进行垃圾回收是一个非常危险的动作。
1700442458
1700442459 之所以危险,是因为System.gc要停止所有的响应(Stop the world),才能检查内存中是否有可回收的对象,这对一个应用系统来说风险极大,如果是一个Web应用,所有的请求都会暂停,等待垃圾回收器执行完毕,若此时堆内存(Heap)中的对象少的话则还可以接受,一旦对象较多(现在的Web项目是越做越大,框架、工具也越来越多,加载到内存中的对象当然也就更多了),那这个过程就非常耗时了,可能0.01秒,也可能是1秒,甚至是20秒,这就会严重影响到业务的正常运行。
1700442460
1700442461 例如,我们写这样一段代码:new String(“abc”),该对象没有任何引用,对JVM来说就是个垃圾对象。JVM的垃圾回收器线程第一次扫描(扫描时间不确定,在系统不繁忙的时候执行)时把它贴上一个标签,说“你是可以被回收的”,第二次扫描时才真正地回收该对象,并释放内存空间,如果我们直接调用System.gc,则是在说“嗨,你,那个垃圾回收器过来检查一下有没有垃圾对象,回收一下”。瞧瞧看,程序主动招来了垃圾回收器,这意味着正在运行着的系统要让出资源,以供垃圾回收器执行,想想看吧,它会把所有的对象都检查一遍,然后处理掉那些垃圾对象。注意哦,是检查每个对象。
1700442462
1700442463 不要调用System.gc,即使经常出现内存溢出也不要调用,内存溢出是可分析的,是可以查找出原因的,GC可不是一个好招数!
1700442464
1700442465
1700442466
1700442467
[ 上一页 ]  [ :1.700442418e+09 ]  [ 下一页 ]