突然想到一个有关问题，可能有点钻牛角：参数用基本类型好还是引用类型好

突然想到一个问题，可能有点钻牛角：参数用基本类型好还是引用类型好?
大定知道java八大基本类型都有其对应的引用类型，关于二者的区别我就不多说了，百度也知道，现看如下代码：
方法一：
public void test(long p1){
  //...
}
方法二：
public void test(Long p2){
  //...
}

当然，这两个方法中，方法二的参数是可以用null的，方法一不行。
但实际运用中，我們不可能传null进来的，（不知道程序前面肯定出问题了），如此一来，方法一和方法二，作用和使用上应该没区别了吧?
但如果非要钻牛角尖，各位大虾认为，这两个方法，用那个更好点呢?(可以从效率啊，习惯啊方面来表述)你們更习惯用那个呢?（当然其实用那个都没有错，呵）
欢迎来讨论。。。。

[最优解释]
基本类型的效率可是要比封装类型的要差不多快7倍，所以对于对数据大量运算的情况下还是用基本数据类型，对于BS的开发实体中的就用封装类吧。
[其他解释]

引用:

引用:基本类型的效率可是要比封装类型的要差不多快7倍，所以对于对数据大量运算的情况下还是用基本数据类型，对于BS的开发实体中的就用封装类吧。
既然基本类型要比引用类型效率方面好这么多，那为何BS中，不用呢?而采用封装类?
其实大部java开发的，都是BS应用啊

实体映射数据库， 你如何能保证你数据路的字段不会是空值？基本数据类型是不能引用null的。
[其他解释]

引用:

基本类型是要快不少，基本类型long存放在栈，运行速度快，还可以共享；而Long是对象，存放在堆，明显要慢不少。
通常在上游如果返回的是Long，不如说数据库查询等等，才会使用Long，扩展性要好一些，可以使用相应的方法。
除了上面这种情况，其他都应该直接使用long，效率高！如果你想用Long的方法，再在方法里面套一层Long.valueOf(long)即可。
同理，其他基本类型都是同样的情况！
[其他解释]
呵呵，LZ，一个基本类型，一个封装类型，不过我参数穿的时候，都是基本类型!
[其他解释]
果断用基本类型，以降低参数复杂度……
[其他解释]
显然用基本类型
[其他解释]
我同意 10 楼的看法，我觉得这才是为什么使用 Long 的原意，
也就是 为什么java 要将 基本数据类型都包装有相对应的 引用数据类型，而作为面向对象。
这不是多次一举.
[其他解释]
大部分时候我见过的都是简单类型，封装类型的只有在做类型转换时采用的，比如将String转换为Integer。


因为没有积分了，没法发帖子，我来搭便车发个问题：
 最近做项目发觉我的jre在执行new Date()时获得的时间是GMT的时间，但同一段代码我的同事获得的却是CST时区的。请问，各位有没有遇到过类似的问题，大家是如何修改jre设置，使new Date()获取的时间是CST时区的。 
[其他解释]

引用:

引用:大部分时候我见过的都是简单类型，封装类型的只有在做类型转换时采用的，比如将String转换为Integer。


因为没有积分了，没法发帖子，我来搭便车发个问题：
 最近做项目发觉我的jre在执行new Date()时获得的时间是GMT的时间，但同一段代码我的同事获得的却是CST时区的。请问，各位有没有遇到过类似的问题，大家是如……

你SimpleDateFormat 这个类格式化你的Date对象。跟你设置的时区木有任何关系！
[其他解释]

引用:

引用:引用:大部分时候我见过的都是简单类型，封装类型的只有在做类型转换时采用的，比如将String转换为Integer。


因为没有积分了，没法发帖子，我来搭便车发个问题：
 最近做项目发觉我的jre在执行new Date()时获得的时间是GMT的时间，但同一段代码我的同事获得的却是CST时区的。请问，……

没有关系么？你看看我的执行结果就知道了。

import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Iterator;
import java.util.Properties;
import java.util.TimeZone;

public class TestTime {
public static void main(String[] args) {
Date date=new Date();
System.out.println("将对象date直接输出: "+date);


TimeZone tz = TimeZone.getTimeZone("ETC/GMT-8"); 
TimeZone.setDefault(tz); 
DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");   
System.out.println(df.format(new Date())); 
System.out.println("-----------------------"); 

Properties props = System.getProperties();
System.out.println("user.timezone=" + props.get("user.timezone"));
}
}

以下是执行结果：
将对象date直接输出: Sat Dec 01 15:31:11 GMT 2012
2012-12-01 23:31:11
-----------------------
user.timezone=GMT

[其他解释]
类型啊类型类型呢
[其他解释]
之所以突然想到这个问题，我看了下自己写代码，发现，自己的代码中并不统一，有的用方法一，有的却用方法二，感觉怪怪的，日后想统一下写法，要么都用方法一，要么都用方法二吧。（哎，有点追求完美主义的倾向，算 是自找麻烦吧，哈）
[其他解释]

引用:

呵呵，LZ，一个基本类型，一个封装类型，不过我参数穿的时候，都是基本类型!

这个当然我知道，两个都能用啊，现在就是想统一掉写法，呵
所以看各位大虾有什么看法，不知道那个写法相对更好点（当然，可能区别可以忽略不计，但要选一种的话，当然还是选相对好的那种了吧）
[其他解释]
周未都没什么人来这边逛了。。。。
现说下自己的看法吧，我觉得应该还是用方法一更好点吧，理由是这样子的，基本类型，在java编译时，应该把参数放在了常量区了，这样调用时是不是会更快点呢（大概这个意思吧，说得不大好，总之觉得效率上应该高点吧）
还有，基本类型，相对来说，也比引用类型少占内存空间吧?（空间上应该占用少点吧?）

不知，元芳，你怎么看呢?
[其他解释]

引用:

果断用基本类型，以降低参数复杂度……

引用:

显然用基本类型

呵，回完才看到，楼上两位跟自己不谋而合。。。。。
[其他解释]

引用:

基本类型的效率可是要比封装类型的要差不多快7倍，所以对于对数据大量运算的情况下还是用基本数据类型，对于BS的开发实体中的就用封装类吧。

既然基本类型要比引用类型效率方面好这么多，那为何BS中，不用呢?而采用封装类?
其实大部java开发的，都是BS应用啊
[其他解释]

引用:

引用:引用:基本类型的效率可是要比封装类型的要差不多快7倍，所以对于对数据大量运算的情况下还是用基本数据类型，对于BS的开发实体中的就用封装类吧。
既然基本类型要比引用类型效率方面好这么多，那为何BS中，不用呢?而采用封装类?
其实大部java开发的，都是BS应用啊
实体映射数据库， 你如何能保证……

这说得倒也有道理。
不过，如果验证数据严格点，完全把NULL的数据转化为0之类的，我认为，应该问题也不大。
当然，这也增加了工作量了，也难免百密一疏吧，为稳定起见，采用封装类，确实可靠性更高吧。
[其他解释]

引用:

大部分时候我见过的都是简单类型，封装类型的只有在做类型转换时采用的，比如将String转换为Integer。


因为没有积分了，没法发帖子，我来搭便车发个问题：
 最近做项目发觉我的jre在执行new Date()时获得的时间是GMT的时间，但同一段代码我的同事获得的却是CST时区的。请问，各位有没有遇到过类似的问题，大家是如何修改jre设置，使new Date……

没遇到过，我觉得，可能跟你机子上的时区设置有关系吧?你把系统设置为北京时区试下。
这应该跟jre没什么关系
[其他解释]
将对象date直接输出: Sat Dec 01 23:59:37 CST 2012
2012-12-01 23:59:37
-----------------------
user.timezone=Asia/Shanghai

上面是我刚测试的结果，下面是我改电脑时区后，输出的结果，很显然，结果不一样
将对象date直接输出: Sat Dec 01 04:02:29 GMT-12:00 2012
2012-12-02 00:02:30
-----------------------
user.timezone=GMT-1200
[其他解释]

你改成北京时区，应该就正常了
[其他解释]
能用基本类型，当然最好，效率高吗

特殊情况，面对比较复杂的时候，用类更好，因为封装了复杂度，更好理解。

查看更多 下一篇