几种自废武功的做法

1、相信谬论

1）链表和数组的速度问题

在我们学习数据结构时，往往会在比较数组和链表之后得出这样的结论：数组在随即存取方面要比链表快，而链表在处理节点的频繁插入删除时性能要优于数组。这句话的前半部分是对的，因为数组有按照索引值随即访问的能力，效率当然比链表的要高。而后半部分就是谬论了。

谬论的产生

数组在计算机中的存储是一块连续的内存，通过索引访问，而链表则是不连续的存储单元，通过指针关联，这个基本知识想必大家都明白。数组中执行插入操作时，将插入点之后的元素依次后移一位，然后将新元素插入到腾出的位置。而进行删除操作时，则是将指定位置的元素删除，之后的元素依次迁移一位。而对于链表，处理方式就简单多了。需要在某个节点之后插入节点的时候，只需要将新节点的后继指向该节点原本的后继，再将该节点的后继指向新节点即可。

稍微思考一下，所有人都会认为数组在这方面效率很差。但是，这个比较从根本上来说是不公平的，无论是链表还是数组，插入和删除操作都需要两个步骤：找到位置和具体进行操作。上面的比较只是比较了执行具体操作的效率，却忽略了找到位置所花的时间。

对于数组来说，查找指定位置就是计算索引，这在计算机中的实现时间可以忽略不计，主要的时间将花费在进行具体操作上。而对于链表来说，找到指定的位置时，整个操作就基本上完成了，因为对链表来说具体操作的时间与寻找指定位置相比，几乎可以忽略不计。因此，上面的比较是有失公允的。

对于计算机来说，数组进行相邻内存内容的复制是非常快的，而链表在查找所进行的寻址操作才是最耗费时间的。

2）Java比C/C++慢

一个Java程序要想被执行手边会被编译成一个class文件，这个类实际上就是一组字节码命令，由凌驾于操作系统之上的Java虚拟机负责对这些字节码进行解释执行。与Java的JVM机制不同，C/C++通过编译器直接编译为操作系统的本地代码，执行起来效率自然要高一些。Java刚面世时，由于各方面还不成熟，的确很多方面都比不上C/C++。

2004年Java SE 5版本是Java发展的里程碑，Java SE 5除了在性能上提升了Java执行效率之外，还推出了一个重要的特性：热点技术和JIT（即时编译）技术。

在一个服务器级的程序中，必然要频繁接受客户端的访问。如果某一个局部的程序模块被多次访问，而其执行效率又相对较慢，则这个模块就成为整个系统的瓶颈。这些访问频率高、严重制约系统性能的模块就称为热点（Hot Spot）。

对于系统中的热点，Java虚拟机中国会调用JIT(Just In Time)技术，将系统热点的字节码翻译成操作系统的本地代码。这样以后再有用户调用这个模块的时候，虚拟机就不会再将其解释执行，而是直接调用本地代码。Java虚拟机会自动检测系统的瓶颈，然后将其转变为操作系统本地代码并进行优化，这种模块执行的自动优化是C/C++所不具备的。

Java和C/C++在两种评测基准（LINPACK(Linear system package,线性系统软件包)测试内容是将一元N次稠密线性代数方程组用高斯消元法求解；而SciMark测试内容为快速傅里叶变换、稀疏矩阵乘法、连续松弛迭代等测试要素）中都和C/C++性能差不多。

2、迷信工具，缺乏纯代码能力

1）迷信ORM

ORM(Object/Relational Mapping)通过将面向对象编程的开发人员所不擅长的关系型数据库处理包装成对象，使得关于数据库的操作对开发人员彻底透明化，在很大程度上简化了开发。不过就像视频格式转换也会有失真，ORM也做不到关系到对象无代价的完美转换。生产环境中有些情况使用ORM做的效果并不够好，或者有些问题干脆就没有办法用ORM来作，如果开发人员过于迷信ORM的话，会很难让自己有技术水平上的真正提高。

做不了的事

面对一些复杂的检索时，尤其是需要进行多层嵌套的统计类检索，ORM就显得力不从心了。而这些复杂问题，采用SQL的高级语法是可以轻松完成的。在ORM里，主要的任务就是将数据映射成对象，由此产生的对象与对象之间的关系要么是一对一的关系，要么是一对多的关系，或是多对多的关系。这目前是ORM的极限，而在实际生产环境中有很多情况都需要进行各种复杂的统计操作，并不是要某个具体对象的信息，这些工作ORM就显得有些力不从心。

做不好的事情

有些问题一般情况下可以使用ORM来解决，但是在某些ORM系统中，有时执行效率将会大大降低，产生诸如“1+n”之类的问题。“1+n”问题就是指如果用一句SQL就解决问题了，但是经过ORM转化后反倒变成了n+1句SQL语句。

比如查询名为A的车主名下所有的车，正常的ORM系统第一步先把A作为对象加载，第二步检索A名下的车的相关信息，所以在ORM中这个过程会被转化为两句SQL，一句查A，一句查A名下的车。

但是在有些情况下，有些ORM系统加载A对象之用了一句SQL，但查找车的信息时却变成了n+1句（n为车的辆数）。这n+1句中第一句是查A名下所有车的ID，并将其存放在一个集合里，然后在对集合中每一个ID执行一句SQL检索，查找车的具体信息。

这种n+1问题在规模不大的情况下，或许还可以忍受。但是如果n值变大，比如说为1000的话，那么执行效率将会降低很多。而对于服务器应用来说，这种性能的降低是致命的。

除了以上两个方面，ORM在实际应用中还存在着一些不足的地方，如下所列。

无法和DBA有效协作，开发人员并不关心数据库操作，结果ORM产生的SQL语句造成系统变慢，而由于是自动产生的SQL语句，数据库分析师（DBA）也无法改动，这样ORM产生的低效语句就变成了双方都无法触及的两不管地带。

产生大量的垃圾数据。ROM封装对象的时候必然会将数据库中对本次检索无用的字段也封装进来，这无疑加大了系统负担，将性能主要浪费在对象的创建上。

有些情况下需要操作的数据无法对象化，比如说只是对某个范围内的自动编号进行操作等，这时ORM就无用武之地了。

对大二进制字段和备注字段还不能用ORM自动处理，需要开发人员自己结合SQL开发解决。

2）神化IDE

身为Java开发人员，应该深入学习Java技术。但是很多人随着学习和工作的不断深入，渐渐的体会到IDE给开发带来的便利，开始进行工作重心的转移，把精通Java的战略目标改为了精通NetBeans、Eclipse等功能强大的IDE，这就有些买椟还珠，本末倒置了。

真正的高手应该通过恰当使用IDE来提高生产效率，但是绝对不能过分迷信IDE。什么能让IDE去做，什么是开发人员必须亲手去做的，每个开发人员都应该区分清楚。这样就能在不影响软件产品质量的前提下最大限度的提高效率，降低成本。

3、浅尝辄止，孤陋寡闻

Java技术发展到今天，虽然历史不够悠久，但是也算得上博大精深。在广而深的Java技术海洋中，很多技术对于Java开发人员来说或者对其研究的不深，浅尝辄止，或者很少听过，有些孤陋寡闻。现在简要介绍几个。

1）finally的忽视

根本就不用

有些菜鸟对于finally根本就不重视，也不会在开发中去使用。这种类型的菜鸟开发的Socket客户端和服务端虽然记得将创建的输入输出流和套接字本身关闭，但却忽略了关闭上述现象时可能产生的异常情况。因此一旦出现异常，将不会执行后面的代码，这样无用的对象将会占用宝贵的内存。