weitom1982

　　"认识你自己"，两千多年前，古希腊的哲人说。古希腊人比较形而上，没有说清楚怎么认识你自己。"管理你自己"，一九九九年，管理大师杜拉克发表文章说。杜拉克深刻而务实，终于向经理人说清楚了怎么认识你自己，而且把"认识"上升到了"管理"的高度。怎么管理你自己？杜拉克说，你要问自己五个问题。

　　第一个问题是：我的长处是什么？很少人真正知道正确答案。你应该向周围的人寻求反馈并加以分析，发现自己真正的长处，然后努力完善自己的长处。同时，找到那些妨碍了自己发挥长处的地方（比如轻视自己专业领域之外的某种重要的技能、或者在人际交往中缺乏应有的礼貌），把它们改掉。

　　第二个问题是：我做事的方式是什么？就像人的长处各有不同，做事方式也各有不同。比如你是"读者"(reader)还是"听者"(listener)？"读者"喜欢看书面资料，"听者"习惯听口头汇报。又比如，你用什么方式学习？最常见的是"听"和"读"，但是也有许多人的主要学习方式是"写"或"说"。

　　在做事方式这个大问题下，要问的小问题还很多。比如，你是擅长团队合作，还是习惯单打独斗？你是擅长做一把手，还是习惯做副手？你是当决策者还是军师？你是在高压之下越战越勇，还是在和平有序的环境下才能出色发挥？你是在大公司还是在小企业更能取得绩效？关键不在于回答这些问题，而在于回答问题后并采取相应的行动。

　　第三个问题是：我的价值观是什么？人和企业都有自己的经营价值观，如果二者冲突，你就难以发挥绩效。比如，如果你信仰内部培养人才而企业喜欢空降外援，你追求长期业绩而企业追求短期结果，你倡导突破性创新而企业愿意持续改善，就是价值观的冲突，而不是谁对谁错的问题。

　　回答前三个问题后，你才能回答第四个问题：我该去哪里工作？或者，你至少知道你不该去哪里工作。知道该对什么样的工作机会说不，知道自己将以怎样的方式做一项新工作，并要求相应的预期和配合。

　　这时该回答第五个问题了：我该贡献什么？要考虑到三方面的因素：一是形势的要求，二是基于自己的长处、做事方式和价值观，怎样能做出最大贡献，三是什么样的结果影响深远。

　　认识你自己之后，要付诸相应的行动，才是管理你自己。

　　工作会议结束后，一些员工一边收拾东西，一边闲聊。你不经意地听到他们的对话，开始琢磨他们言谈中表现出来的情绪。

　　其中一个员工说："你是斗不过人事部的，他们总会找些理由让你的医疗费报不了。"另一个说："是吗？我不知道这回事，我还没有报过医疗费呢。"

　　你摇了摇头，走开了。你很遗憾听到公司的老员工把一种消极的态度传递给了新员工。根据你的经验，报销医疗费本身是件很复杂的事，人事部并没有故意找茬使事情难办。事实上，起因通常是员工自己没能提供足够的信息，或者没有及时交上报销单据才使事情变得麻烦的，员工却把自己的错误归咎到人事部头上。那么，你该怎么做呢？这只是个闲聊，与你无关，是吗？

　　员工的消极对话会影响士气和工作态度，一旦这种消极的情绪传播开来，将使你激发员工积极性的努力功亏一篑，所以每个经理人都应该认真对待这个问题。

　　在上述例子中那个发牢骚的员工觉得自己是"受害者"，并把这种"受害"情绪传递给他人。你不希望如此，因为这样会让别的员工泄气。

　　为了对付消极谈话的潜在危险，识别四种有关的"带情绪的谈话"是有益的。如果你能认清这些消极方式，并把它转化成积极方式，就会鼓起你自己和同事的工作干劲。

变消极为积极

　　这种消极谈话主要使我们下意识地受到限制和约束，要解决这个问题就要想法绕开约束或者干脆摆脱它们。

　　当你碰到障碍时，是想办法绕过去，还是放弃？关键在于你对这个障碍是怎么想和怎么表述的，比如说：你要求员工将一份长篇报告复印许多份，明天一早送到相关人员手里。这时只剩半个小时取邮包的就要来了，偏偏复印机又坏了，办公大楼内其他复印机也不能正常工作，那该怎么办呢？

　　你不想让员工和其他人消极地对待困难，应该说"把这个报告送出去有点困难，我想知道有什么方法可以克服这个困难？"

　　为了确保员工能积极回应，你所说的每句话都应该朝积极的方向努力。当你听到有人说"干不了"，你应该把他们向"能做到"的积极方向引导。比如，你可以建议扫描后把报告打印出来，或者通过E-mail把报告发给收件人。也就是说，积极地寻找替代方案的关键在于积极思考，而积极地思考往往能产生新点子，这样就不会鼓励员工放弃，而是让他们在现有条件下想办法。

变狭隘为开放

　　狭隘指的是当你遇到困难时，认为只有一种或少数几种方法解决。比如说"Fred非常健忘，我想我不应该再把重要的工作交给他。"就是一种狭隘的说法，让你不想做点什么去改变Fred的健忘。狭隘的表述，使你先入为主，从而禁锢你的思想。

　　为了避免消极对话，你经常需要把对话转向积极的、创新的讨论。这样有助于员工开放思想，不钻牛角尖。

　　假如你听到一个经理在抱怨他的员工，不满意这个员工的工作表现。这位经理很沮丧，觉得这个员工自己不想努力，他说："我不知道该怎么做，我可以炒他鱿鱼或者听之任之，但我真的不愿意这样做。"

　　如果你让他只在前面两个方案中选择，这个经理就不能有效地解决这个问题。你可以说一些很简单的道理："既然你不想采用以上两种办法，那么你可以想想别的办法。比如说让他每天给你交一份工作汇报，或者给他配一个导师，带着他一起把工作做好。"你的建议也许并不合适，但提醒了这个经理还有许多选择。
变责备为理解

　　这种消极的谈话方式在企业里表现为"追究责任"。不管什么时候，你听到人们评价、责备自己或他人时，你应该立即把这种消极的对话转向积极的对话。你可以敦促人们更广泛地了解事情的来龙去脉来达到这个目的。

　　比如说，当一条产品线落后于正常进度的时候，经理可能会说："这是谁的责任？我想知道那些拖了我们后腿的生产车间工人的名字。"这就是一个"追究责任"的例子，这不可能改变目前的生产状况，也不能避免将来再次出现类似的情况。    经理人应该从另一个角度提问："为什么会发生这样的事情？我们生产工序中的哪个部分出了问题才导致了产量下降？我们应该做些什么来改进工序以避免同样的问题再次发生？"这样的提问将鼓励员工去积极思索、提出建议而不是为自己开脱。

　　当然，改变"追究责任"的方式带来的好处远不止在质量管理领域。当有人做了"错事"或"坏事"，或犯了错误，如果你真的想从中吸取经验教训，你应该问为什么会发生这个事，而不是去追究责任。当你找到了哪个"为什么"，而不是找到是"谁"干的，你就会了解事情的起因，做出调整，避免将来再犯错。

变对抗为合作

　　对抗影响士气，让人们相互谴责，把精力耗费在扩大分歧上，而不是群策群力，共图大业。况且，感情上的伤害还会妨碍在工作中相互合作。

　　你应该怎么处理这种对抗性的消极谈话呢？对策就是，鼓励人们问一问别人为什么要这么做，而不是告诉他应该怎么做。

　　比如说，Ray向你抱怨Lyn很懒惰，借喝咖啡休息很长时间；而Lyn抱怨几乎不可能和Ray共事，因为他很粗鲁又不体谅人。你该做些什么让他们重归于好呢？

　　首先，你需要弄清楚真相，最好让他们自己去发现。为什么Ray会在意Lyn喝咖啡时间的长短呢？为什么Lyn会觉得Ray粗鲁又不体谅人呢？如果你问了这些问题，就会发现：Ray的座位挨着Lyn，如果Lyn离开座位，Ray就要帮她接电话。Lyn回忆说几天前她离开了相当长一段时间回来后，Ray就说她偷懒，这让她很伤心，所以就不再和Ray说话。

　　为了让他们重归于好，你应该运用理解力。只要理解了别人为什么那样做，你就不会做出愤怒的反应，而是建设性地沟通以化解矛盾。

　　避免消极谈话，倡导积极谈话，比物质刺激更能起到激励作用。这是一项高回报的投资，无须成本就能带来巨大的回报：高涨的热情，干劲十足的员工和高效的业绩。

  查看数据库中有无多余的索引，即一个索引的字段为另一个索引的前几个字段。如index1的定义为test(filed1,filed2),index2的定义为test(filed1,filed2,filed3)，则认为index1是多余的。(摘自Ixora)

						column redundant_index format a39
column sufficient_index format a39

select /*+ ordered */
  o1.name||'.'||n1.name  redundant_index,
  o2.name||'.'||n2.name  sufficient_index
from
  (
    select
      obj#,
      bo#,
      count(*)  cols,
      max(decode(pos#, 1, intcol#))  leadcol#
    from
      sys.icol$
    group by
      obj#,
      bo#
  )  ic1,
  sys.icol$  ic2,
  sys.ind$  i1,
  sys.obj$  n1,
  sys.obj$  n2,
  sys.user$  o1,
  sys.user$  o2
where
  ic2.obj# != ic1.obj# and
  ic2.bo# = ic1.bo# and
  ic2.pos# = 1 and
  ic2.intcol# = ic1.leadcol# and
  i1.obj# = ic1.obj# and
  bitand(i1.property, 1) = 0 and
  ic1.cols * (ic1.cols + 1) / 2 =
  ( select
      sum(xc1.pos#)
    from
      sys.icol$ xc1,
      sys.icol$ xc2
    where
      xc1.obj# = ic1.obj# and
      xc2.obj# = ic2.obj# and
      xc1.pos# = xc2.pos# and
      xc1.intcol# = xc2.intcol#
  ) and
  n1.obj# = ic1.obj# and
  n2.obj# = ic2.obj# and
  o1.user# = n1.owner# and
  o2.user# = n2.owner#
/
				

SDK提供了有序集合接口java.util.List的几种实现，其中三种最为人们熟知的是Vector、ArrayList和LinkedList。有关这些List类的性能差别是一个经常被问及的问题。在这篇文章中，我要探讨的就是LinkedList和Vector/ArrayList之间的性能差异。

为全面分析这些类之间的性能差异，我们必须知道它们的实现方法。因此，接下来我首先从性能的角度出发，简要介绍这些类的实现特点。

一、Vector和ArrayList的实现

Vector和ArrayList都带有一个底层的Object[]数组，这个Object[]数组用来保存元素。通过索引访问元素时，只需简单地通过索引访问内部数组的元素：

内部数组可以大于Vector/ArrayList对象拥有元素的数量，两者的差值作为剩余空间，以便实现快速添加新元素。有了剩余空间，添加元素变得非常简单，只需把新的元素保存到内部数组中的一个空余的位置，然后为新的空余位置增加索引值：

把元素插入集合中任意指定的位置（而不是集合的末尾）略微复杂一点：插入点之上的所有数组元素都必须向前移动一个位置，然后才能进行赋值：

剩余空间被用光时，如果需要加入更多的元素，Vector/ArrayList对象必须用一个更大的新数组替换其内部Object[]数组，把所有的数组元素复制到新的数组。根据SDK版本的不同，新的数组要比原来的大50%或者100%（下面显示的代码把数组扩大100%）：

Vector类和ArrayList类的主要不同之处在于同步。除了两个只用于串行化的方法，没有一个ArrayList的方法具有同步执行的能力；相反，Vector的大多数方法具有同步能力，或直接或间接。因此，Vector是线程安全的，但ArrayList不是。这使得ArrayList要比Vector快速。对于一些最新的JVM，两个类在速度上的差异可以忽略不计：严格地说，对于这些JVM，这两个类在速度上的差异小于比较这些类性能的测试所显示的时间差异。

通过索引访问和更新元素时，Vector和ArrayList的实现有着卓越的性能，因为不存在除范围检查之外的其他开销。除非内部数组空间耗尽必须进行扩展，否则，向列表的末尾添加元素或者从列表的末尾删除元素时，都同样有着优秀的性能。插入元素和删除元素总是要进行数组复制（当数组先必须进行扩展时，需要两次复制）。被复制元素的数量和[size-index]成比例，即和插入/删除点到集合中最后索引位置之间的距离成比例。对于插入操作，把元素插入到集合最前面（索引0）时性能最差，插入到集合最后面时（最后一个现有元素之后）时性能最好。随着集合规模的增大，数组复制的开销也迅速增加，因为每次插入操作必须复制的元素数量增加了。

二、LinkedList的实现

LinkedList通过一个双向链接的节点列表实现。要通过索引访问元素，你必须查找所有节点，直至找到目标节点：

把元素插入列表很简单：找到指定索引的节点，然后紧靠该节点之前插入一个新节点：

线程安全的LinkedList和其他集合
如果要从Java SDK得到一个线程安全的LinkedList，你可以利用一个同步封装器从Collections.synchronizedList(List)得到一个。然而，使用同步封装器相当于加入了一个间接层，它会带来昂贵的性能代价。当封装器把调用传递给被封装的方法时，每一个方法都需要增加一次额外的方法调用，经过同步封装器封装的方法会比未经封装的方法慢二到三倍。对于象搜索之类的复杂操作，这种间接调用所带来的开销不是很突出；但对于比较简单的方法，比如访问功能或者更新功能，这种开销可能对性能造成严重的影响。

这意味着，和Vector相比，经过同步封装的LinkedList在性能上处于显著的劣势，因为Vector不需要为了线程安全而进行任何额外的间接调用。如果你想要有一个线程安全的LinkedList，你可以复制LinkedList类并让几个必要的方法同步，这样你可以得到一个速度更快的实现。对于所有其它集合类，这一点都同样有效：只有List和Map具有高效的线程安全实现（分别是Vector和Hashtable类）。有趣的是，这两个高效的线程安全类的存在只是为了向后兼容，而不是出于性能上的考虑。

对于通过索引访问和更新元素，LinkedList实现的性能开销略大一点，因为访问任意一个索引都要求跨越多个节点。插入元素时除了有跨越多个节点的性能开销之外，还要有另外一个开销，即创建节点对象的开销。在优势方面，LinkedList实现的插入和删除操作没有其他开销，因此，插入-删除开销几乎完全依赖于插入-删除点离集合末尾的远近。

三、性能测试

这些类有许多不同的功能可以进行测试。LinkedList应用比较频繁，因为人们认为它在随机插入和删除操作时具有较好的性能。所以，下面我分析的重点将是插入操作的性能，即，构造集合。我测试并比较了LinkedList和ArrayList，因为这两者都是非同步的。

插入操作的速度主要由集合的大小和元素插入的位置决定。当插入点的位置在集合的两端和中间时，最差的插入性能和最好的插入性能都有机会出现。因此，我选择了三个插入位置（集合的开头、末尾和中间），三种典型的集合大小：中等（100个元素），大型（10,000个元素），超大型（1,000,000个元素）。

在本文的测试中，我使用的是JAVA SDK 1.2.0和1.3.0系列的SUN JVM。此外，我还用HOTSPOT JVM 2.0进行了测试，这个版本可以在1.3.0 SDK找到。在下面的表格中，各个测量得到的时间都以其中一次SDK 1.2 VM上的测试时间（表格中显示为100%的单元）为基准显示。测试期间使用了默认的JVM配置，即启用了JIT编译，因此对于所有JVM，堆空间都必须进行扩展，以避免内存溢出错误。表格中记录的时间是多次测试的平均时间。为了避免垃圾收集的影响，在各次测试之间我强制进行了完全的内存清理（参见测试源代码了解详情）。磁盘监测确保磁盘分页不会在测试过程中出现（任何测试，如果它显示出严重的磁盘分页操作，则被丢弃）。所有显示出数秒应答时间的速度太慢的测试都重复进行，直至记录到一个明显合理的时间。

对于规模较小的集合，ArrayList和LinkedList的性能很接近。当元素插入到集合的末尾时，即追加元素时，ArrayList的性能出现了突变。然而，追加元素是ArrayList特别为其优化的一个操作：如果你只想要一个固定大小的静态集合，Java数组（例如Object[]）比任何集合对象都具有更好的性能。除了追加操作，测量得到的时间数据差别不是很大，它们反映了各个JVM的优化程度，而不是其他什么东西。

例如，对于把元素插入到集合的开始位置来说（表1的前两行），HotSpot 2.0 JVM加LinkedList具有最好的性能（85.3%），处于第二位的是 1.2 JVM加ArrayList（100%）。这两个结果显示出，1.2中简单的JIT编译器在执行迭代和复制数组等简单的操作时具有很高的效率。在HotSpot中复杂的JVM加上优化的编译器能够改进复杂操作的性能，比如对象创建（创建LinkedList节点），并能够利用代码内嵌（code-inlining）的优势。1.3 JVM的结果似乎显示出，在简单操作方面它的性能有着很大的不足，这一点很可能在以后的JVM版本中得到改进。

在这里我特别进行测试的是ArrayList相对于LinkedList的另一个优点，即预先确定集合大小的能力。具体地说，创建ArrayList的时候允许指定一个具体的大小（例如，在测试中ArrayList可以创建为拥有100个元素的容量），从而避免所有随着元素增多而增加集合规模的开销。表1括号中的数字显示了预先确定集合大小时性能的提高程度。LinkedList（直到 SDK 1.3）不能预先确定大小。

此外，ArrayList只生成少量的需要进行垃圾收集的对象，即，用来保存元素的内部数组对象，以及每次ArrayList容量不足需要进行扩展时创建的附加内部数组对象。LinkedList不管可能出现的任何删除操作，都为每一个插入操作生成一个节点对象。因此，LinkedList会给垃圾收集器带来相当多的工作。考虑到这些因素，对于任何中小规模的集合，我会选择使用ArrayList而不是LinkedList。

表2显示了大规模集合的测试结果。可以看到，在出现大规模插入操作的时候，我们开始遭遇严厉的性能惩罚。正如我们前面分析类的实现所得到的结果，对于LinkedList来说最差的情形出现在把元素插入到集合中间时。另外我们还可以看到，与使用ArrayList时把元素插入到集合开头的最差性能相比，使用LinkedList时把元素插入到集合中间的性能更差一些。和这两种性能最差的情况相比，把元素插入到ArrayList中间的性能显然要好得多。

总地看来，ArrayList再一次在大多数情形下表现出更好的性能，包括根据索引把元素插入到随机位置的情形。如果你总是要把元素插入到集合中靠前的位置，LinkedList具有更好的性能；然而，此时你可以利用一个反向的ArrayList得到更好的性能，即，使用一个专用的实现，或者通过[size -index]映射翻转索引在集合中的位置。

表3显示了超大集合的测试结果，从该表可以得出的结论与表2非常相似。然而，表3强调的是，超大集合要求数据、集合类型、数据处理算法之间的恰到好处的配合；否则，你将得到事实上不可接受的性能表现。至于性能优化，你可以构造一个针对该问题的专用集合类。对于超大集合来说，为了获得可接受的性能，构造专用集合类往往是很有必要的。

四、查询的性能

在类的内部实现查询时查询的性能最高。对于查询这些列表来说，迭代所有元素所需要的时间是一个限制因素。ArrayList/Vector类中实现的查询将对类的元素进行迭代。下面的例子计算空元素的总数量：

表4显示出，ArrayList的性能显著地超过了LinkedList，它再一次显示出ArrayList应该是我们首选的类。表5显示了利用从List.listIterator(int)获得的ListIterator对象迭代所有元素所需要的时间，如果查询机制不能在List内部实现，这些迭代器是必需的。ArrayList再一次显示出了较高的性能，但这次性能的差异程度不象表4显示的那样不可思议。注意，表5所显示的绝对时间相当于表4显示绝对时间的10倍，即，ArrayList内部遍历大约比ArrayList利用ListIterator迭代要快10倍。

■ 结束语
实际测量和我们所考虑的其他因素都清楚地显示出，ArrayList和Vector通常比LinkedList和同步封装之后的LinkedList有着更好的性能。即使在你认为LinkedList可能提供更高性能的情况下，你也可以通过修改元素加入的方式从ArrayList争取更好的性能，例如翻转集合元素的次序。

有些情况下LinkedList会有更好的性能，例如，当大量元素需要同时加入到大型集合的开头和末尾时。但一般而言，我建议你优先使用ArrayList/Vector类，只有当它们存在明显的性能问题而LinkedList能够改进性能时，才使用LinkedList。