所谓临时变量，就是为了方便起见申明的变量，存放一些中间结果。有点像中学几何里
面的辅助线。
如果基于性能的考虑，避免每次调用的时候为临时变量分配空间，就可以将它声明为成
员变量，例如临时压缩缓冲区。
如果基于性能的考虑，避免每次访问的时候访问成员变量（尤其在循环的时候），就可
以将它声明为临时变量。
如果要在避免在函数之间传递大量参数，也可以用成员变量来节约参数个数和占用的空
间
面的辅助线。
如果基于性能的考虑，避免每次调用的时候为临时变量分配空间，就可以将它声明为成
员变量，例如临时压缩缓冲区。
如果基于性能的考虑，避免每次访问的时候访问成员变量（尤其在循环的时候），就可
以将它声明为临时变量。
如果要在避免在函数之间传递大量参数，也可以用成员变量来节约参数个数和占用的空
间
变量可以在任何类中申明，但是逻辑关系要清楚。
我认为同意那个高手的意见.全局变量是不应该使用的.
在java中也不存在全局变量的概念.
如果是全局的就用单例.
全局变量会导致使用的扩散,无法控制对该变量的调用.
而且对于现在的趋势,硬件的成本远远低于软件的成本.
原来楼主要讨论的是变量是应该在方法外声明还是在方法内声明
我认为同意那个高手的意见.全局变量是不应该使用的.
在java中也不存在全局变量的概念.
如果是全局的就用单例.
全局变量会导致使用的扩散,无法控制对该变量的调用.
而且对于现在的趋势,硬件的成本远远低于软件的成本.
原来楼主要讨论的是变量是应该在方法外声明还是在方法内声明
这一点我想的不多，只认为最简单的原则是：
用来耦合的在方法外声明，否则一律在方法内部声明，不必要的存在只会造成不必要的错误
面向对象程序设计中，我不习惯再叫什么‘全局变量’。而叫类成员。在同一个类当中，只要能够使用（
不考虑静态成员和非静态成员的访问控制），那就是全局的，类方法中的参数，是局部的。
在类中，如果对类成员‘读’的地方比较多，我觉得设计往往是合理的，如果‘写’的地方比较多，我建
议尽量做成参数传递，然后提供一个公共方法读取。
静态成员对于类实例来说，就有点‘全局变量’的味道了。
Java程序中 ,不能在所有类之外定义全局变量 ,只能通过在一个类中定
义公用、静态的变量来实现一个全局变量。例如 :
义公用、静态的变量来实现一个全局变量。例如 :
Class GlobalVar{
public static global_var;
}
public static global_var;
}
在类 GlobalVar中定义变量 global_var为 public stat-ic,使得其它类
可以访问和修改该变量。
可以访问和修改该变量。
=========================================
这是全局变量的定义，如果有可能的话，尽量使用局部变量为好
这是全局变量的定义，如果有可能的话，尽量使用局部变量为好
“private HashMap hm;//呵呵，我称此种为全局变量”
其实，“全局”与“局部”也是相对而言的，相对于类的内部，可以认为是“全局”的。相对于其它的类
，也可以认为是“局部”的。如果某一private变量拥有getter或/和setter，我们还可以称之为“属性”
。
我觉得，在编程实践中，用哪一种方式，完全是根据实际需要而定。不应象楼主说的那位“高手”那样做
强制的要求。
还有一点，面向对象的思想强调的是“对象和对象的有机联系”，那么，一个类中如果就只有方法，那么
跟以前面向过程编程一样了吗？这样做是不是违背了面向对象的初衷呢？
> >
错了，其实不完全是这样的。因为很有可能这个类本身的存在，就是面向对象的一个部分。比如，俺给你
> >
错了，其实不完全是这样的。因为很有可能这个类本身的存在，就是面向对象的一个部分。比如，俺给你
举一个简单的例子来说明吧：
一个配置加载的类比如说ConfigLoader从配置文件中加载配置信息，配置可能是这样的nv对：
name : value.
作为客户来说，并不需要关心这个value是什么，可能只是需要根据这个value创建出来的一些结果，比如
一个配置加载的类比如说ConfigLoader从配置文件中加载配置信息，配置可能是这样的nv对：
name : value.
作为客户来说，并不需要关心这个value是什么，可能只是需要根据这个value创建出来的一些结果，比如
配置类名通过反射机制来创建就可以了。
那么通常ConfigLoader这么做：假设使用HashMap来存储：
final Map map = new HashMap();
// ... 读取配置文件的内存
for(each:...) {
String name = each.getName();
String value = each.getValue();
Object actualValue = build(value);
map.put(name, actualValue);
}
Object build(String value) {...}
// ..
这样是一种通常的做法，但是如果细了说，ConfigLoader这个类实际上有两个职责了：
(1) 加载配置文件。
(2) 根据指定的value来构建对象实例。
可能会导致的问题是，第一构建方法的变化会导致ConfigLoader这个不相关的类的修改，第二，对单元测
那么通常ConfigLoader这么做：假设使用HashMap来存储：
final Map map = new HashMap();
// ... 读取配置文件的内存
for(each:...) {
String name = each.getName();
String value = each.getValue();
Object actualValue = build(value);
map.put(name, actualValue);
}
Object build(String value) {...}
// ..
这样是一种通常的做法，但是如果细了说，ConfigLoader这个类实际上有两个职责了：
(1) 加载配置文件。
(2) 根据指定的value来构建对象实例。
可能会导致的问题是，第一构建方法的变化会导致ConfigLoader这个不相关的类的修改，第二，对单元测
试增大了难度，至少看起来不是一个优美可测的结构。
因此，在这样的情况下，就可以把构建的内容单独抽离到一个新的对象中去做：
class Builder {
Object build(String value) {...}
}
刚才的程序片断就简单变为：
map.put(each.getName(), new Builder().build(each.getValue());
这样，即便构建的逻辑发生变化，对于ConfigLoader来说是没有任何影响的。
class Builder {
Object build(String value) {...}
}
刚才的程序片断就简单变为：
map.put(each.getName(), new Builder().build(each.getValue());
这样，即便构建的逻辑发生变化，对于ConfigLoader来说是没有任何影响的。
楼主可以看看比如Builder这个类，它本身没有任何变量，就是提供了一个build的方法。。但是它本身就
是体现了面向对象的一个部分，它承担了构建这个责任。
=================
另外，也有变成面向过程的编程，通常就是俺们经常使用的工具类，就是做的面向过程的事情。
final public class Utils {
private Utils() {}
public static void someMethod(...) {...}
}
这个someMethod就是一个典型的面向过程的东西。
当然要记住，这样的写法并不是完全不可取的。。在需要的场合，很大程度上这样是一个不错的解决方式
另外，也有变成面向过程的编程，通常就是俺们经常使用的工具类，就是做的面向过程的事情。
final public class Utils {
private Utils() {}
public static void someMethod(...) {...}
}
这个someMethod就是一个典型的面向过程的东西。
当然要记住，这样的写法并不是完全不可取的。。在需要的场合，很大程度上这样是一个不错的解决方式
。
再说了，我经常看到有类似下面的声明：
public class Test{
private String s;
protected HashMap hm;
private List list;
public ... ...
public Test(){
s = "test ";
hm = new HashMap();
list = new ArrayList();
... ...
}
}
private String s;
protected HashMap hm;
private List list;
public ... ...
public Test(){
s = "test ";
hm = new HashMap();
list = new ArrayList();
... ...
}
}
可以这么说，凡是在构造方法中创建的变量都是这种意义上的局部变量，那就是说，如果其为非private的
话，那么是提供给别的类访问用的，是可以声明为这种意义上的全局变量的，那么如果是private的话，那
么本就不应该这么去创建和声明？？？而应该尽可能得把它放在局部去声明和创建，应用的时候，靠方法
的参数和返回值来通信？？？？
jvm对于内存资源的回收需要等待一个collection周期，而不是实时回收。
如果对一个变量的使用率频繁建议使用全局。可以节省CUP分配内存空间的时间。
如果使用局部变量。虽然在整个程序运行期内存资源消耗减少。可是CUP要花更多时间用在内存资源分配上
。
过去，使用面向过程的编程方法时，时常讨论“局部变量”和“全局变量”的问题。
早期(20世纪80年代或更早)没有结构化程序设计思想或方法时，变量都是“全局”的，即整个程序可以访
问到每一个变量。
后来(20世纪80年代至90年代)，有了结构化程序设计思想，程序员们就觉得，哎呀，用局部变量怎么能行
呢？全局变量多好呀，程序想怎么写就怎么写，有了一个变量，想在哪用就在哪用，想怎么用就怎么用。
可是，没过多久，思想转变了，程序员们又觉得，还是少用全局变量好呀！你看，我们写的程序，结构多
么清晰呀，读来就象一股清泉，简直就是一部艺术作品呢！
现在，我们采用的是面向对象的思想和方法！全局变量在哪里呢？根本就没有嘛。我们只有被称作“类成
员”的东西！
“类成员”可以称为“全局变量”吗？姑且称之。且慢！如果是private的，还能称之为“全局变量”吗？
好，好，就算它们全部是public的，是否所有的数据全都要由“类成员”保管吗？如果是的话，我们应该
考虑一下，就与“面向对象”的思想可能就是背道而驰的了。
谢谢上面的朋友们：
我说的全局变量就是指同时有几个方法都要用到的变量，这些变量可以说会经常被使用，方法可以基于它
们进行通信，我觉得如果要是写成局部变量的话，那么很多方法都会有入参和返回值，这样不便于阅读和
理解代码啊
在上面，大家异口同声得回答局部变量，原因基本上是：
1.资源消耗少
2.最少通信原则
2.最少通信原则
我也同意这点，但是这和“类内部强耦合”相冲突，希望多讨论讨论这方面～～～～～～
再一个，对于“2.我们写的类到时候要被多线程调用的，所以局部变量更好一点”这一点，我的想法是：
“变量是全局的还是局部的，和多线程调用并无关系，到时只要在总方法上加上synchronized就
好，而且，即使变量是局部的，要是多线程调用时，也得加上同步不是？”
“变量是全局的还是局部的，和多线程调用并无关系，到时只要在总方法上加上synchronized就
好，而且，即使变量是局部的，要是多线程调用时，也得加上同步不是？”
也请在这一点上多发言～～～～～～～～
再次谢谢大家的发言～
局部变量是避免多线程造成变量非同步操作错误的有效措施
越小域的变量越安全，当一个变量超出它所应用的范围后，他剩余的时光只是浪费资源和造成错误
局部变量是避免多线程造成变量非同步操作错误的有效措施
越小域的变量越安全，当一个变量超出它所应用的范围后，他剩余的时光只是浪费资源和造成错误
要看那种情况，假如你的这个变量是作为循环体内使用，那么用“全局”吧，如：
Student student=null;
for(Iterator iter=datas.iterator();iter.hasNext();){
student=(Student)iter.next();
}
这样可以节约时间，不用没一次循环都要在栈中申请空间以存储引用；
假如是在类一级的，比如作为类的属性还是方法的变量，原则是假如方法的参数不是很多的话，那么采用方法传递，楼主也说了，可以采用多线程或是池。
使用java也有两年了，以前是用局部变量多一点，后来自己体会到，还是全局变量更能体现面向对象的思想：类的内部应该体现强耦合性，类和类之间应该体现弱耦合性；再说了，每个类要是只是方法堆砌出来的，也没有意思了。
但是近来，和一个高手做项目，他却要求除过把几个不太变化的对象声明为全局变量外，其它的变量都是用局部变量，我们这个项目比较庞大一点，他的理由是:
1.全局变量始终占用内存，多了一笔开销
2.我们写的类到时候要被多线程调用的，所以局部变量更好一点
1.全局变量始终占用内存，多了一笔开销
2.我们写的类到时候要被多线程调用的，所以局部变量更好一点
我觉得，使用全局变量和使用局部变量相比，内存好像是多占用了一点，但是不会造成内存不足，
而且，变量是全局的还是局部的，和多线程调用并无关系，到时只要在总方法上加上synchronized就
好，而且，即使变量是局部的，要是多线程调用时，也得加上同步不是？
而且，变量是全局的还是局部的，和多线程调用并无关系，到时只要在总方法上加上synchronized就
好，而且，即使变量是局部的，要是多线程调用时，也得加上同步不是？
很久之前就开始遵循一个原则：变量的最小作用域原则。
即是尽量不要扩大一个变量的可见范围。
