垃圾收集解决所有的内存问题
对于java程序员而言，垃圾收集功能是一个非常大的帮助，同时也是使用java语言的一个非常大的优势。 然而，实际情况应该是不能因为垃圾收集可以清除无用的内存就不去考虑内存问题。这里要指明的是， 如果忽略这个问题，那么就会导致问题。
首先，在不同的JVM上垃圾收集算法是不同的，因此，如果你想你的程序能够很好的运行在不同的JVM上，那么就不能依赖垃圾收集的特定行为。垃圾收集是一个非常活跃的研究问题，更好、更快并且更精确的收集器总在实现中。
然而很多现代的垃圾收集器都有着同样的问题。其中一个是当他们运行时并非总是释放所有那些可以被收集的对象。
分析表明java编程中大多对象的生存期是短暂的，因此，对于需要提高性能的收集器而言，他们会减少检查那些具有较长生命的对象的频度，这个是依据大多对象具有较短的生存期，而那些生存期较长的对象往往会被继续引用，因此，没有必要在每次检查时都去检查这样的对象是否可以被回收。
要释放特定的对象的内存可能需要多次调用垃圾收集。你可以通过调用System.gc方法建议（注意是建议）垃圾收集器运行。请求这个方法的结果通常导致垃圾收集器进行一次完整的收集。通常这个比VM调用垃圾收集要更彻底和完全，也会尽可能快的完成。如果程序员显式的调用System.gc，那么推论是有更多的时间做更多的工作（请注意是有更多的事情做更多的事情，这意味着将进行大量的检查,还记得刚才的有关对长短生命期对象的检查的频度的变化吗？而不是真正彻底的清除）。在任何一种情况下（显式调用垃圾收集和VM调用垃圾收集）都不要假设所有可以被收集的对象会真正的被收集。
显式的调用System.gc有更大的机会完成彻底的收集，但不是保证会完成。
另一个程序员会遇到的麻烦是他们往往保持对那些不再需要的对象的引用。这将阻止垃圾收集器释放该对象。
这种情况在你自己管理列表的时候会发生。
考虑下面的ObjStack类。这个类使用push和pop方法管理堆栈中的对象。两个方法都利用索引，该索引指明堆栈中下一个可用的位置。push方法存储对新对象的引用并增加索引值，而pop方法减小索引值并返回堆栈最上面的元素。
实例一：没有正确实现pop方法的ObjStack
class ObjStack
{
private Object[] stack;
private int index;
public void push(Object o)
{
stack[index] = o;
index++;
}
public Object pop()
{
index-;
return stack[index];
}
//...
}
现在创建一个容量为10的对象，然后调用8次push方法向它添加对象，那么此时索引值为8。
现在考虑三次调用pop方法后发生什么？此时的索引值为5，但是请注意，除了这个索引值发生变化外堆栈其实没有其它任何变化！
虽然pop方法减小了索引值，但是实际上堆栈仍然保持着对那些对象的引用。调用pop方法往往意味着那些对象应该被收集（大多情况是如此的，即使不是马上，也是在稍后使用完该对象后）。然而由于堆栈仍然保留有对该对象的引用，它就不能被收集。这些对象只能在调用push后被替换才可能被收集。正确的pop的实现如下：
public Object pop()
{
index-;
Object o = stack[index];
stack[index] = null;
return o;
}
在这个版本的pop方法中，当引用被返回后，堆栈删除对他们的引用因此垃圾收集器在以后可以回收他们。
在你自己的编码中，对于那些不需要的对象，不要在引用它们！程序的执行极大收到可用内存的影响，可用内存越少，那么垃圾收集的执行次数越多，这将极大的伤害性能。
破除java神话之二：参数是传址的
在不同的java新闻组中，参数是传值还是传址一直是一个经常被争辩的话题。误解的中心是以下两个事实：
对象是传引用的
参数是传值的
这两个能够同时成立吗？一个字：是！在java中，你从来没有传递对象，你传递的仅仅是对象的引用！一句话，java是传引用的。然而，当你传递一个参数，那么只有一种参数传递机制：传值！
通常，当程序员讨论传值和传引用时，他们是指语言的参数传递机制，c++同时支持这两种机制，因此，以前使用过c++的程序员开始好像不能确定的java是如何传参数的。java语言为了事情变得简单只支持参数传值的机制。
java中的变量有两种类型：引用类型和原始类型。当他们被作为参数传递给方法时，他们都是传值的。这是一个非常重要的差别，下面的代码范例将说明这一点。在继续前，我们有必要定义一下传值和传引用。
传值意味着当参数被传递给一个方法或者函数时，方法或者函数接收到的是原始值的副本。因此，如果方法或者函数修改了参数，受影响的只是副本，原始值保持不变。
关于java中的参数传递的混乱是因为很多java程序员是从c++转变过来的。c++有引用和非引用类型的变量，并且分别是通过传引用和传值得。java语言有原始类型和对象引用，那么，按照逻辑，java对于原始类型使用传值而对引用是传引用的，就像c++一样。毕竟，你会想到如果你正在传递一个引用，那么它一定是传引用的。这是一个很诱惑人的想法，但是是错误的！
在c++和java中，当函数的参数不是引用时，你传递的是值得副本（传值）。但是对于引用类型就不同了。在c++中，当参数是引用类型，你传递的是引用或者内存地址（传引用），而在java中，传递一个引用类型的参数的结果只是传递引用的副本（传值）而非引用自身。
这是一个非常重要的区别！java不考虑参数的类型，一律传递参数的副本。仍然不信？如果java中是传引用，那么下面的范例中的swap方法将交换他们的参数。因为是传值，因此这个方法不是像期望的那样正常工作。
class Swap
{
public static void main(String args[])
{
Integer a, b;
int i,j;
a = new Integer(10);
b = new Integer(50);
i = 5;
j = 9;
System.out.println("Before Swap, a is " + a);
System.out.println("Before Swap, b is " + b);
swap(a, b);
System.out.println("After Swap a is " + a);
System.out.println("After Swap b is " + b);
System.out.println("Before Swap i is " + i);
System.out.println("Before Swap j is " + j);
swap(i,j);
System.out.println("After Swap i is " + i);
System.out.println("After Swap j is " + j);
}
public static void swap(Integer ia, Integer ib)
{
Integer temp = ia;
ia = ib;
ib = temp;
}
public static void swap(int li, int lj)
{
int temp = li;
li = lj;
lj = temp;
}
}
上面程序的输出是:
Before Swap, a is 10
Before Swap, b is 50
After Swap a is 10
After Swap b is 50
Before Swap i is 5
Before Swap j is 9
After Swap i is 5
After Swap j is 9
因为swap方法接收到的是引用参数的副本（传值），对他们的修改不会反射到调用代码。
译者注：在传递引用和原始类型时还是有不同的，考虑以下的代码：
class Change
{
public static void main(String args[])
{
StringBuffer a=new StringBuffer("ok");
int i;
i = 5;
System.out.println("Before change, a is " + a);
change(a);
System.out.println("After change a is " + a);
System.out.println("Before change i is " + i);
change(i);
System.out.println("After change i is " + i);
}
public static void change(StringBuffer ia)
{
ia.append(" ok?");
}
public static void change(int li)
{
li = 10;
}
}
程序的输出为：
Before change, a is ok
After change a is ok ok?
Before change i is 5
After change i is 5
即如果传递的是引用，那么可以修改引用对象的内容，这个改变会影响到原来的对象，而传递的如果是原始类型则不会有影响。这个也是造成误解的原因之一吧。
破除Java神话之三：原子操作都是线程安全的
Java中原子操作是线程安全的论调经常被提到。根据定义，原子操作是不会被打断地的操作，因此被认为是线程安全的。实际上有一些原子操作不一定是线程安全的。
这个问题出现的原因是尽量减少在代码中同步关键字。同步会损害性能，虽然这个损失因JVM不同而不同。
另外，在现代的JVM中，同步的性能正在逐步提高。尽管如此，使用同步仍然是有性能代价的，并且程序员永远会尽力提高他们的代码的效率，因此这个问题就延续了下来。
在java中，32位或者更少位数的赋值是原子的。在一个32位的硬件平台上，除了double和long型的其它原始类型通常都是使用32位进行表示，而double和long通常使用64位表示。另外，对象引用使用本机指针实现，通常也是32位的。对这些32位的类型的操作是原子的。
这些原始类型通常使用32位或者64位表示，这又引入了另一个小小的神话：原始类型的大小是由语言保证的。
这是不对的。ja
