业精于勤荒于嬉,行成于思毁于随

Oracle数据库查询一个月的记录的sql语句:

select LASTUPDTIME from spprereg where
    (to_date('2005-5-1','YYYY-mm-dd')-LASTUPDTIME)<0  and
    (LAST_DAY(to_date('2005-5-1','YYYY-mm-dd'))-LASTUPDTIME)>0

这是我的一个朋友写的，转给大家看看。

　从某种意义上来说，打工真是害人不浅，长期的打工固化了人的思维，淡化了人的责任感，扼杀了人的创新思维，没有成本概念，缺乏长远规划。最为关键的是，打工打得越久，看问题的视角就越悲观，自己也就越自卑。
   
　　一群老板聚在一起，大家所交流的话题大多是商业环境，以及如何更好地发展生意等等。向对方展示的也是自己光辉灿烂的一面和发展的一面。
   
　　一群打工者聚集在一起，牢骚往往占了多数，骂老板刻薄，埋怨工作量大且与收入不对称等等，很少有打工者对自己目前的状况满意的，向对方展示的也更多的是自己没有得到重用没有得到发挥的一面。当然，有牢骚未必是不重视自己的工作，因为“嫌货的才是买货的”。留心一下你就会发现，人在跳槽前反而异常平静，而成天把跳槽挂嘴边的人一般是那些一直做下去的人。
   
　　为什么打工者会选择用语言而不是实干来获得心理平衡呢？这与打工者抱着一个什么样的心态在打工密不可分。
   
　　笔者从1994年出道，打了四年工，跳出来自己开公司当老板，因根基不稳，一年后破产，又出来打工，四年后，又跳出来开公司当老板。在每次从打工者到老板，又由老板到打工者的转换过程中，都难免要经历一次耗时数月的心态调整和角色转换，逼着自己进行换位思考，每次的转换与脱一次皮也差不了多少。
   
　　生意后来做大了，打算让太太来帮我接管我原来的那家公司，我自己重开一家，可太太打了八年工，接管公司后却把公司搞得乱七八糟。追查原因，原来太太还是按照打工的那一套在管理公司，我又足足花了两年时间来帮助太太实现由一个打工者向老板的转换。由此想到，如今报纸杂志电视上招商广告到处飞，好像有点资本就可以当老板了，好像老板可以速成？其实这就是许多创业以失败告终的原因。
   
　　根据自己在老板与打工者角色之间不断转换的过程，我总结出以下老板与打工者心态的几点不同：
   
　　长远目标与短期行为
   
　　作为一个真正意义上的老板，知道自己最终想要什么，要达到目标需要经过哪些过程，具备长远眼光，拥有战略意识。而作为打工者，着眼点也就是当前这两三年，往往第一考虑的还是安全感，如何保住现有的饭碗，自然不会想得太远，也不会太高。而且，很少有打工者能进行换位思考，站到老板的角度去看问题和考虑问题。也就造成很多打工者很难与老板沟通。
   
　　解决问题与完成工作
   
　　老板对一件工作的完成定义是指把某件事彻底被解决，今天能搞定的一定不拖到明天。而打工者会习惯性地把工作按照天数来分解，每天只完成部分工作，下班时间一到心里就习惯性地想回家，剩下的工作明天再做，在公司里多待一分钟都不愿意。
   
　　单个环节与整个系统
   
　　打工者接到一个指派工作任务后，进行处理或是分解后转交给其他同事，然后在他看来，这事就差不多算完了，反正他负责的这块已经做完了，至于转交出去的工作是否被保质保量按时完成，那就不是他要操心的范围了。长此以往，许多打工者已经习惯只管自己的二亩三分地，严重缺少整体系统概念。而老板常常看的是整个任务的完成。
   
　　推脱责任与承担失败
   
　　在一个企业或是公司里，我们最常见到的就是在出现事故后，老板要追查责任人，大家异常统一、步调一致地互相推卸责任，极少有人会站出来承认自己工作的不足。打工打久了，遇到问题首先想到的是回避，然后就是设法推给别人。这样一来，打工者也就愈加不可能从失败和失利中学习、吸取教训。其实，老板们的成长就是从一个个自己承担失败，并从中总结分析了问题原因所在、积累经验而来的。
   
　　个人意识与联合力量
   
　　很多的打工者脑海中都存在着个人英雄主义，总希望在一些事情上表露一下，在老板面前表表功，为了不被其他同事抢了功劳，所以有时候就会冒一定的风险（当然是以公司的资源为成本的）一个人单枪匹马干点什么出来，当然，要是出了娄子，最后还得由公司承担，很少有打工者们会从降低成本及风险、或是提高效率的角度出发，去主动联合其他同事，共同完成某项任务。
   
　　大手大脚与成本概念
   
　　作为老板，公司的每一分钱的支出都会算作是成本，省下来的就是利润，所以，精打细算是许多老板的习惯性思维和行为。而打工者们却是大方得很，反正公司的资产是老板的，只要自己工作方便顺手，浪费点又算什么，以至于许多打工者在自己做老板的时候，还改变不了在打工时养成的大手大脚的习惯。
   
　　办事一条线和思维多样化
   
　　条条大路通罗马，完成工作不止一种方法，但打工者长期打工生涯下来，已经习惯了用单一思维去考虑问题，A事就用A类解决办法，B事就用B类解决办法，很少会去用超越性的思维来从多角度多方向来探讨问题的解决办法。
   
　　从某种意义上来说，打工真是害人不浅，长期的打工固化了人的思维，淡化了人的责任感，扼杀了人的创新思维，没有成本概念，缺乏长远规划。最为关键的是，打工打得越久，看问题的视角就越悲观，自己也就越自卑。
   
　　所以提醒各位，即使一时不能当老板，也要抱着老板的心态去打工

“嫁个有钱人”不如自己成为有钱人，你想发财吗？你知道如何成为有钱人吗？

1、做你真正感兴趣的事——你会花很多时间在上面，因此你一定要感兴趣才行，如果不是这样的话，你不愿意把时间花在上面，就得不到成功。

2、自己当老板。为别人打工，你绝不会变成巨富，老板一心一意地缩减开支，他的目标不是使他的职员变成有钱人。

3、提供一种有实效的服务，或一种实际的产品。你要以写作、绘画或作曲变成百万富翁的机会可以说是无限小，而你要在营造业、房地产、制造业发大财的机会比较大。记住，出版商赚的钱比作家多得多。

4、如果你坚持要用自己的灵感来创业？最好选择娱乐业，在这方面，发财的速度相当快，流行歌曲和电视最理想。

5、不论你是演员或商人，尽量增加你的观众。在小咖啡馆唱歌的人，所赚的钱一定比不上替大唱片公司灌唱片的人，地方性的商人，不会比全国性的商人赚的钱多。

6、找出一种需要，然后满足它。社会越变越复杂，人们所需要的产品和服务越来越多，最先发现这些需求而且满足他们的人，是改进现有产品和服务的人，也是最先成为富翁的人。

7、不要不敢采用不同的方式——新的方法和新产品，会造成新的财富。但必须确定你的新方法比旧方法更理想，你的新方法必
想致富,请栽摇钱 引爆数码影像!
中华川菜火锅大联 加盟乐可可天天乐

须增进产品外观、效率、品质、方便或者降低成本。

8、如果你受过专业教育，或者有特殊才能，充分利用它。如果你烧得一手好菜，而却要去当泥水匠，那就太笨了。

9、在你着手任何事情之前，仔细地对周围的情形研究一番。政府机关和公共图书馆，可以提供不少资料，先做研究，可以节省你不少时间和金钱。

10、不要一直都想着发大财，不如你想想如何改进你的事业，您应该常常问自己的是：“我如何改良我的事业？”如何使事业进行顺利，财富就会跟着而来。

11、可能的话，进行一种家庭事业，这种方法可以减少费用，增进士气，利润的分配很简单，利润能够得到充分的利用，整个事业控制也较容易。

12、尽可能减少你的费用，但不能牺牲你的品质，否则的话，你等于是在慢性自杀，赚钱的机会不会大。

13、跟同行的朋友维持友谊——他们可能对你很有帮助。

14、把尽量多的时间花在事业上。一天12小时、一星期6天是最低要求，一天14小时到18小时很平常，一星期工作7天最好了。你必须先牺牲家庭和社会上的娱乐，直到你事业站稳为止。也只有到那时候，你才能把责任分给别人。

15、不要不敢自己下决心。听听别人的赞美和批评，但你自己要下决心。

16、不要不敢说实话。拐弯抹角，只会浪费时间，心里想什么就说什么，而且要尽可能地直截了当地、明确地说出来。

17、不要不敢承认自己的错误。犯了错误并不是一种罪行，犯错不改才是罪过。

18、不要因为失败就裹足不前。失败是难免的，也是有价值的，从失败中，你会学到正确的方法论。

19、不要在不可行的观念上打转。一发现某种方法行不通，立即把它放弃。世界上有无数的方法，把时间浪费在那些不可行的方法上是无可弥补的损失。

20、不要冒你承担不起的风险。如果你损失10万元，若损失得起的话，就可以继续下去，但如果你赔不起5万元，而一旦失败的话，你就完蛋了。

21、一再投资，不要让你的利润空闲着，你的利润要继续投资下去，最好投资别的事业或你控制的事业上，那样，才能钱滚钱，替你增加好几倍的财富。

22、请一位高明的律师——他会替你节约更多的金钱和时间，比起你所给予的将要多的多。

23、请一位精明的会计师。最初的时候，你自己记账，但除非你本身是个会计师，你还是请一位精明的会计师，可能决定你的成功和失败——他是值得你花钱的。

24、请专家替你报税。一位机灵的税务专家，可又替你免很多的税。

25、好好维持你的健康和你的平静心灵——否则的话，拥有再多的钱也没有什么意思。

多疑，敏感，天真，犹豫不决，胆怯，多虑

-如果有就赶快克服它。

 

1.了解你的精力充沛期。通常人们在早晨9点左右工作效率最高，可以把最困难的工作放到这时来完成。

　　2.集中一天中的头两个小时来处理手头的工作并不接电话、不开会、不受打扰。这样可以事半功倍。

　　3.立刻回复重要的邮件，将不重要的丢弃。若任它们积累成堆，反而更费时间。

　　4.做个任务清单，将所有的项目和约定记在效率手册中。手头一定要带着效率手册以帮助自己按计划行事。

　　5.学会高效地利用零碎时间，用来读点东西或是构思一个文件，不要发呆或做白日梦。

　　6.把琐碎的工作写在单子上，以便有零碎时间时马上去做。

　　7.并非每件工作都值得精工细做，有些事只要过得去就可以了。一遍又一遍地写些琐碎的备忘录不是高效利用时间的做法。

　　8.减少回电话的时间。如果你需要传递的只是一个信息，不妨在工作以外的时间在录音电话上留言，或是发个电子邮件。

　　9.如果有人在电话中喋喋不休地讲话，你可以礼貌地结束电话。

　　10.对可能打来的电话做到心中有数，这样在你接到所期待的电话后便可迅速找到所需要的各种材料，不必当时乱翻乱找。

　　11.学习上网高效搜寻的技能，以节省上网查询的时间。把你经常要浏览的网站收集起来以便随时找到。

　　12.用国际互联网简化商业旅行的安排。多数饭店和航线可以网上查询和预订。

　　13.只要情况允许就可委派别人分担工作。事必躬亲会使自己疲惫不堪，而且永远也做不完。不妨请同事帮忙，或让助手更努力地投入。

　　14.做个灵活的日程表，当你需要时便可以忙中偷闲。例如，在中午加班，然后早一小时离开办公室去健身，或是每天工作10个小时，然后用星期五来赴约会、看医生。

　　15.在离开办公室之前开列次日工作的清单，这样第二天早晨一来便可以全力以赴。

Java中支持方法名相同，但是方法参数不同而自动去选择执行哪一个方法，如print(int i)和print(String str),虽然方法名相同，但是参数不同。象这里的int和String 参数差异比较大所以看起来这种重载没什么差别，但是如果是类型差别不大， 会出现什么情况呢？

   看下面的代码：

    public void f(float i){
        System.out.println("float");
    }

    public viod f(double i){
       System.out.println("double");
   }

    那么执行 f(5)会输出什么呢？5是被认为是float类型还是double类型还是会报错呢？执行结果是 float 。原来在这种情况下，该数据类型能被转为一个较大的数据类型，比5较大的数据类型是float,其次才到double,所以输出结果是float。还有一个特殊的情况就是如果输入类型为char,如这里我们执行f('a'),

不要以为这会出错，其实是不会出错的，因为如果没有发现一个准确的char于它匹配，那么它就把这个char转换成int类型，如果没有int类型和它匹配，在去寻找较大的数据类型，这里它找到了float,所以这里执行flaot('a')输出的还是 float。

  下面再讨论另外一种情况，譬如说下面这种情况:

   定义了下面一个方法：

  public void f(int i){
    System.out.println("int ");
}

  如果执行f(100.99)会不会在这种数据类型大于这种重载方法期待的变量时会怎么处理呢？会不会把这种较大的数据类型缩小到期待的数据类型？编译一下，很遗憾出错了，在这种情况下是出错的。

这么快就12点半了，睡觉了~~~不然明天早晨爬不起来了。

虽然Java中goto语句只是java的一个保留字，没有起任何作用，但是我今天在使用continue和break语句时，还是发现了其中又goto语句的影子。因为continue和break语句都支持跳到一个Label的位置。下面是具体的用法：

  inner:
  for( int  i = 0 ; i<3 ;i++ ){
   System.out.println("iiii===>"+i); 
   for( int j =0 ; j<5; j++ ){
    if( j == 1 )
      continue  inner;
    System.out.println("j===>"+j); 
   }
  }

上面一段语句的输出为

iiii===>0
j===>0
iiii===>1
j===>0
iiii===>2
j===>0

一般的 continue语句都是跳出当前循环，但是这个会跳出到标记inner的位置。

 

Java中检查两个对象是否相等，这个看起来很简单的事情但是实际做起来不一定是一个简单的事情。我们可能首先想到的是＝＝运算符号，但是这个运算符真的能比较两个对象么？我们先看下面一段代码：

   public static void main(String [] argv ){

        Integer    A = new Integer(47);

       Integer     B = new Integer(47);

      System.out.println( A == B ) ;

     System.out.println( A != B );

}

可能你觉得输出的结果是true false ,但是结果正好相反，是：false,true。不要觉得奇怪，因为＝＝实际比较的是两个对象的句柄，而不是对象的内容，所以 A==B输出为false,    而A != B  输出为false.

可能以为equals方法能帮我们解决这个问题，那么来试一下，

class Value {
  int i;
}

public class EqualsMethod2 {
  public static void main(String[] args) {
    Value v1 = new Value();
    Value v2 = new Value();
    v1.i = v2.i = 100;
    System.out.println(v1.equals(v2));
  }
} ///:~
结果输出的并不是我们所希望的true,而是false,这是因为类默认的equal方法是直接比较句柄的，而不是我们所希望的比较内容，所以我们不得不发现我们要比较两个类的内容我们不得不在类中重写equal()方法来实现比较两个类的内容。

 

原出处:http://dev.csdn.net/article/20/20614.shtm

(1) 类名首字母应该大写。字段、方法以及对象（句柄）的首字母应小写。对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定义中出现了常数初始化字符，则大写static final基本类型标识符中的所有字母。这样便可标志出它们属于编译期的常数。
Java包（Package）属于一种特殊情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名扩展名称，如com，org，net或者edu等，全部都应小写（这也是Java 1.1和Java 1.2的区别之一）。

(2) 为了常规用途而创建一个类时，请采取“经典形式”，并包含对下述元素的定义：

equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable

(3) 对于自己创建的每一个类，都考虑置入一个main()，其中包含了用于测试那个类的代码。为使用一个项目中的类，我们没必要删除测试代码。若进行了任何形式的改动，可方便地返回测试。这些代码也可作为如何使用类的一个示例使用。

(4) 应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。理想情况下，方法应简明扼要。若长度很大，可考虑通过某种方式将其分割成较短的几个方法。这样做也便于类内代码的重复使用（有些时候，方法必须非常大，但它们仍应只做同样的一件事情）。

(5) 设计一个类时，请设身处地为客户程序员考虑一下（类的使用方法应该是非常明确的）。然后，再设身处地为管理代码的人考虑一下（预计有可能进行哪些形式的修改，想想用什么方法可把它们变得更简单）。
(6) 使类尽可能短小精悍，而且只解决一个特定的问题。下面是对类设计的一些建议：
■一个复杂的开关语句：考虑采用“多形”机制
■数量众多的方法涉及到类型差别极大的操作：考虑用几个类来分别实现
■许多成员变量在特征上有很大的差别：考虑使用几个类

(7) 让一切东西都尽可能地“私有”——private。可使库的某一部分“公共化”（一个方法、类或者一个字段等等），就永远不能把它拿出。若强行拿出，就可能破坏其他人现有的代码，使他们不得不重新编写和设计。若只公布自己必须公布的，就可放心大胆地改变其他任何东西。在多线程环境中，隐私是特别重要的一个因素——只有private字段才能在非同步使用的情况下受到保护。

(8) 谨惕“巨大对象综合症”。对一些习惯于顺序编程思维、且初涉OOP领域的新手，往往喜欢先写一个顺序执行的程序，再把它嵌入一个或两个巨大的对象里。根据编程原理，对象表达的应该是应用程序的概念，而非应用程序本身。

(9) 若不得已进行一些不太雅观的编程，至少应该把那些代码置于一个类的内部。

(10) 任何时候只要发现类与类之间结合得非常紧密，就需要考虑是否采用内部类，从而改善编码及维护工作（参见第14章14.1.2小节的“用内部类改进代码”）。

(11) 尽可能细致地加上注释，并用javadoc注释文档语法生成自己的程序文档。

(12) 避免使用“魔术数字”，这些数字很难与代码很好地配合。如以后需要修改它，无疑会成为一场噩梦，因为根本不知道“100”到底是指“数组大小”还是“其他全然不同的东西”。所以，我们应创建一个常数，并为其使用具有说服力的描述性名称，并在整个程序中都采用常数标识符。这样可使程序更易理解以及更易维护。

(13) 涉及构建器和异常的时候，通常希望重新丢弃在构建器中捕获的任何异常——如果它造成了那个对象的创建失败。这样一来，调用者就不会以为那个对象已正确地创建，从而盲目地继续。

(14) 当客户程序员用完对象以后，若你的类要求进行任何清除工作，可考虑将清除代码置于一个良好定义的方法里，采用类似于cleanup()这样的名字，明确表明自己的用途。除此以外，可在类内放置一个boolean（布尔）标记，指出对象是否已被清除。在类的finalize()方法里，请确定对象已被清除，并已丢弃了从RuntimeException继承的一个类（如果还没有的话），从而指出一个编程错误。在采取象这样的方案之前，请确定finalize()能够在自己的系统中工作（可能需要调用System.runFinalizersOnExit(true)，从而确保这一行为）。

(15) 在一个特定的作用域内，若一个对象必须清除（非由垃圾收集机制处理），请采用下述方法：初始化对象；若成功，则立即进入一个含有finally从句的try块，开始清除工作。

(16) 若在初始化过程中需要覆盖（取消）finalize()，请记住调用super.finalize()（若Object属于我们的直接超类，则无此必要）。在对finalize()进行覆盖的过程中，对super.finalize()的调用应属于最后一个行动，而不应是第一个行动，这样可确保在需要基础类组件的时候它们依然有效。

(17) 创建大小固定的对象集合时，请将它们传输至一个数组（若准备从一个方法里返回这个集合，更应如此操作）。这样一来，我们就可享受到数组在编译期进行类型检查的好处。此外，为使用它们，数组的接收者也许并不需要将对象“造型”到数组里。

(18) 尽量使用interfaces，不要使用abstract类。若已知某样东西准备成为一个基础类，那么第一个选择应是将其变成一个interface（接口）。只有在不得不使用方法定义或者成员变量的时候，才需要将其变成一个abstract（抽象）类。接口主要描述了客户希望做什么事情，而一个类则致力于（或允许）具体的实施细节。

(19) 在构建器内部，只进行那些将对象设为正确状态所需的工作。尽可能地避免调用其他方法，因为那些方法可能被其他人覆盖或取消，从而在构建过程中产生不可预知的结果（参见第7章的详细说明）。

(20) 对象不应只是简单地容纳一些数据；它们的行为也应得到良好的定义。

(21) 在现成类的基础上创建新类时，请首先选择“新建”或“创作”。只有自己的设计要求必须继承时，才应考虑这方面的问题。若在本来允许新建的场合使用了继承，则整个设计会变得没有必要地复杂。

(22) 用继承及方法覆盖来表示行为间的差异，而用字段表示状态间的区别。一个非常极端的例子是通过对不同类的继承来表示颜色，这是绝对应该避免的：应直接使用一个“颜色”字段。

(23) 为避免编程时遇到麻烦，请保证在自己类路径指到的任何地方，每个名字都仅对应一个类。否则，编译器可能先找到同名的另一个类，并报告出错消息。若怀疑自己碰到了类路径问题，请试试在类路径的每一个起点，搜索一下同名的.class文件。

(24) 在Java 1.1 AWT中使用事件“适配器”时，特别容易碰到一个陷阱。若覆盖了某个适配器方法，同时拼写方法没有特别讲究，最后的结果就是新添加一个方法，而不是覆盖现成方法。然而，由于这样做是完全合法的，所以不会从编译器或运行期系统获得任何出错提示——只不过代码的工作就变得不正常了。

(25) 用合理的设计方案消除“伪功能”。也就是说，假若只需要创建类的一个对象，就不要提前限制自己使用应用程序，并加上一条“只生成其中一个”注释。请考虑将其封装成一个“独生子”的形式。若在主程序里有大量散乱的代码，用于创建自己的对象，请考虑采纳一种创造性的方案，将些代码封装起来。

(26) 警惕“分析瘫痪”。请记住，无论如何都要提前了解整个项目的状况，再去考察其中的细节。由于把握了全局，可快速认识自己未知的一些因素，防止在考察细节的时候陷入“死逻辑”中。

(27) 警惕“过早优化”。首先让它运行起来，再考虑变得更快——但只有在自己必须这样做、而且经证实在某部分代码中的确存在一个性能瓶颈的时候，才应进行优化。除非用专门的工具分析瓶颈，否则很有可能是在浪费自己的时间。性能提升的隐含代价是自己的代码变得难于理解，而且难于维护。

(28) 请记住，阅读代码的时间比写代码的时间多得多。思路清晰的设计可获得易于理解的程序，但注释、细致的解释以及一些示例往往具有不可估量的价值。无论对你自己，还是对后来的人，它们都是相当重要的。如对此仍有怀疑，那么请试想自己试图从联机Java文档里找出有用信息时碰到的挫折，这样或许能将你说服。

(29) 如认为自己已进行了良好的分析、设计或者实施，那么请稍微更换一下思维角度。试试邀请一些外来人士——并不一定是专家，但可以是来自本公司其他部门的人。请他们用完全新鲜的眼光考察你的工作，看看是否能找出你一度熟视无睹的问题。采取这种方式，往往能在最适合修改的阶段找出一些关键性的问题，避免产品发行后再解决问题而造成的金钱及精力方面的损失。

(30) 良好的设计能带来最大的回报。简言之，对于一个特定的问题，通常会花较长的时间才能找到一种最恰当的解决方案。但一旦找到了正确的方法，以后的工作就轻松多了，再也不用经历数小时、数天或者数月的痛苦挣扎。我们的努力工作会带来最大的回报（甚至无可估量）。而且由于自己倾注了大量心血，最终获得一个出色的设计方案，成功的快感也是令人心动的。坚持抵制草草完工的诱惑——那样做往往得不偿失。

(31) 可在Web上找到大量的编程参考资源，甚至包括大量新闻组、讨论组、邮寄列表等。下面这个地方提供了大量有益的链接：

  Java中c中的指针的概念，但是我在使用中还是碰到过一些问题，如我把一个一个对象A赋值给对象B时，这两个对象有一个改变，那么另外一个也相应的改变。下面分别谈谈这可能发生问题的几种情况:

<一>从“一个对象到另一个对象的赋值”，如:

        Class  A = new Class();

       Class  B  = A;

       这种情况实际把句柄从一个地方复制到另外一个地方，这种情况下对象B和A实际指向的是同一个句柄，更新B会影响到A,同样更新A也会影响到B。

<二>把对象作为方法的参数传递到一个方法中。Java方法的参数传递可以分成两种：一种是值传递，这种一般是简单的数据类型，如int,long,double,char这些等；一种类似是c中的引用传递，就是把对象作为一个引用传递给方法参数，在这种情况下，在方法中把这个传入的参数对象改变，那么相应的传入这个参数引用的对象也相应的改变。如:

     Number A = new Number();
     A.num   = 9;
     test(A);

     方法定义:

    public  void   test(Number n){
      n.num = 99;
    }

   那么A的num值会变成99.

<三>;把对象保存在ArrayList中.如果把一个对象保存在一个AyyayList中，如果这个对象再发生改变，那么在这个ArrayList中保存的对象也会改变，说白了还是两个还是公用同一个句柄.如:

   Number A = new Number();
     A.num = 100;
     java.util.ArrayList list = new ArrayList();
     list.add(A);
     A.num = 999;
     Number B = (Number)list.get(0);
     System.out.println(B.num);

那么输出为999,对象A的更改影响到了ArrayList中的保存的对象.