真正让我吃惊的是自定义序列化机制。

而这些方法是私有的!!，它们会在对象序列化期间被JVM“神秘地”调用。

private void writeObject(ObjectOutputStream out) throws IOException;
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException;

通过这种方式，您可以创建自己的自定义序列化，使其更加“随便”(安全、快速、罕见、简单等)。

如果大量信息必须通过节点传递，这是真正应该考虑的事情。序列化机制可以更改为发送数据的一半。很多时候，瓶颈并不在平台上，而是在通过线路发送的数量上，这可能会为您节省数千个硬件dll。

这是一篇文章。 http://java.sun.com/developer/technicalArticles/Programming/serialization/

我知道这是在1.5版中添加的，但是新的enum类型是一个很棒的特性。不必使用旧的“int enum模式”极大地帮助了我的一堆代码。看看JLS 8.9的甜肉汁你的土豆!

Javadoc——在正确编写的情况下(不幸的是，一些开发人员并不总是这样)，它会为您提供一个清晰、连贯的描述，说明代码应该做什么，而不是它实际做什么。然后可以将其转换为一组不错的可浏览的HTML文档。如果你使用持续集成等方法，它可以定期生成，这样所有开发者都可以看到最新的更新。

JDK 1.6_07+包含一个名为VisualVM (bin/jvisualvm.exe)的应用程序，它是许多工具之上的一个漂亮的GUI。它似乎比JConsole更全面。

The power you can have over the garbage collector and how it manages object collection is very powerful, especially for long-running and time-sensitive applications. It starts with weak, soft, and phantom references in the java.lang.ref package. Take a look at those, especially for building caches (there is a java.util.WeakHashMap already). Now dig a little deeper into the ReferenceQueue and you'll start having even more control. Finally grab the docs on the garbage collector itself and you'll be able to control how often it runs, sizes of different collection areas, and the types of algorithms used (for Java 5 see http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html).

如果你做了很多JavaBean开发，并且使用了属性更改支持，你通常会写很多这样的setter:

public void setFoo(Foo aFoo){
  Foo old = this.foo;
  this.foo = aFoo;
  changeSupport.firePropertyChange("foo", old, aFoo);
}

我最近无意中发现了一篇博客，它提出了一个更简洁的实现，使代码更容易编写:

public void setFoo(Foo aFoo){
  changeSupport.firePropertyChange("foo", this.foo, this.foo = aFoo);
}

它实际上简化了事情，以至于我能够在Eclipse中调整setter模板，从而自动创建方法。