今天花了一整天在跟踪一个问题，每次感觉已经快找到原因的时候发现现象又变了，我觉得从中吸取的教训可以给大家分享一下。

从上个世纪90年代Java诞生之日起，Java的类和资源的加载就一直是个问题。由于它增加了启动和初始化时间，因此这个问题在Java应用服务器上则尤为明显。为了缓解这个问题，大家试过了不同的访问，比如说以exploaded方式部署，但这只对简单的应用有效；还有2001年发明的Java热插拔的机制。启用热插拔的话，你在一个现有的方法内的改动马上就会生效。由于方法的边界限制，这个方法并不是特别有用，通常它只是在调试的阶段使用。对于现在的应用来说，编译，部署以及重启，等待个5到15分钟已经不是什么稀奇事儿了。越大型的应用服务器，这种情况可能就越明显。

译注：其实语言都没有高下之分，适合当前工作的就是好语言。不过这位作者在这方面的一些态度的确值得我们学习，人家并不是盲目的乱喷，而是摆出数据，有理有据。本来想说老外在这方面怎么怎么样的，后来想了想，地图炮还是少开，毕竟这么说有失偏颇。

HashMap是一个高效通用的数据结构，它在每一个Java程序中都随处可见。先来介绍些基础知识。你可能也知道，HashMap使用key的hashCode()和equals()方法来将值划分到不同的桶里。桶的数量通常要比map中的记录的数量要稍大，这样每个桶包括的值会比较少（最好是一个）。当通过key进行查找时，我们可以在常数时间内迅速定位到某个桶（使用hashCode()对桶的数量进行取模）以及要找的对象。

在twitter，需要网络功能的核心模块使用的都是Netty。 比方说：

可变长参数列表是Java 5中的一个新特性。如果方法需要传入多个同类型参数的话，这个功能就非常有用。比如说，Java 5之前如果要写一个方法来将所有入参打印到控制台上的话，它的代码会是这样的：

译注：但见新人笑，哪闻旧人哭。在大家都在兴致勃勃的讨论Java 8的时候，那个早被遗忘的Java 7，或许你从来都没有记得它的好。

我喜欢新鲜玩意儿，而Java 8里面就有不少。这回我准备介绍一下我的一个最爱——并发计数器。这是一组新的类，用于维护多个线程并发读写的计数器。新的API带来了显著的性能提升，同时还保证了接口的简单易用。

本系列文章译自Venkat Subramaniam的Functional Programming in Java

复杂的东西我们可不喜欢。一直以来，内存泄露，线程锁，GC调优这些东西处理起来都很痛苦。这三个邪恶的小伙伴带来的性能问题是最难复现的，这也使得修复这些问题有如噩梦一般。如果你不信的话，看一下LinkedIn最近关于性能调优的一篇文章就知道了。