public class TestFinal
{
//只有定义成 final User user 才不会报错为什么?
public void test( User user)
{
(new Thread()
{
public void run()
{
System.out.println("user.name-->"+user.name);
}
}
).start();
}
public static void main(String[] args)
{
User user=new User();
user.setId(007);
user.setName("zhaoyang");
TestFinal testFinal=new TestFinal();
testFinal.test(user);
}
}
class User
{
String name=null;
int id;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
19 个解决方案
#1
为了保证内部实现与外在表现的一致性。
具体请看:
http://blog.csdn.net/axman/archive/2006/12/25/1460544.aspx
具体请看:
http://blog.csdn.net/axman/archive/2006/12/25/1460544.aspx
#2
1楼神了,记下来ψ(._. )>
#3
答:
1)从程序设计语言的 理论上: 局部内部类(即:定义在方法中的内部类),由于本身就是在方法内部(可出现在形式参数定义处或者方法体处),因而 访问方法中的局部变量(形式参数或局部变量)是 天经地义的.是很自然的
2)为什么JAVA中要加上一条限制:只能访问final型的局部变量?
3)JAVA语言的编译程序的设计者当然全实现:局部内部类能访问方法中的所有的局部变量(因为:从理论上这是很自然的要求),但是: 编译技术是无法实现的或代价极高.
4)困难在何处? 到底难在哪儿?
局部变量的生命周期与局部内部类的对象的生命周期的不一致性!
5)设方法f被调用,从而在它的调用栈中生成了变量i,此时产生了一个局部内部类对象inner_object,它访问了该局部变量i .当 方法f()运行结束后,局部变量i就已死亡了,不存在了.但:局部内部类对象inner_object还可能一直存在(只能没有人再引用该对象时,它才会死亡),它不会随着方法f()运行结束死亡.这时:出现了 一个"荒唐"结果:局部内部类对象inner_object 要访问一个已不存在的局部变量i!
6)如何才能实现?当变量是final时,通过将 final局部变量"复制"一份,复制品直接作为局部内部中的数据成员.这样:当局部内部类访问局部变量时,其实真正访问的是这个局部变量的"复制品"(即:这个复制品就代表了那个局部变量).因此:当运行栈中的 真正的局部变量死亡时,局部内部类对象仍可以访问局部变量(其实访问的是"复制品"),给人的感觉: 好像是局部变量的"生命期"延长了.
那么: 核心的问题是:怎么才能使得: 访问"复制品"与 访问真正的 原始的局部变量,其 语义效果是一样的呢?
当变量是final时,若是基本数据类型,由于其值不变,因而:其复制品与原始的量是一样.语义效果相同.(若:不是final,就无法保证:复制品与原始变量保持一致了,因为:在 方法中改的是原始变量,而局部内部类中改的是复制品)
当变量是final时,若是引用类型,由于其引用值不变(即:永远指向同一个对象),因而:其复制品与原始的引用变量一样,永远指向同一个对象(由于是final,从而保证:只能指向这个对象,再不能指向其它对象),达到:局部内部类中访问的复制品与方法代码中访问的原始对象,永远都是同一个即:语义效果是一样的. 否则:当方法中改原始变量,而局部内部类中改复制品时,就 无法保证:复制品与原始变量保持一致了(因此:它们原本就应该是同一个变量.)
一句话:这个规定是一种无可奈何.也说明:程序设计语言的 设计是 受到实现技术的限制的.这就是一例. 因为:我就看到不少人都持这种观点:设计与想法是最重要的,实现的技术是无关紧要的,只要你作出设计与规定,都能实现.
#4
6的理由很牵强了。
“当变量是final时,通过将final局部变量"复制"一份”
这不是final的理由,因为从编译实现上,当普通局部变量传给匿名类的时候同样可以“复制”。
其实就是传给匿名类的构造方法,使方法中的局部变量和匿名类中同时拥有这个对象的引用。
但真正的原因就在这里,当外面的方法重新赋值的时候,不影响内部类的句柄指向那个对象,
即外部的变量指向A而匿名类的变量却指向B了,这才是不能接受的结果。
因为从源程序上看它们是同一变量。
“当变量是final时,通过将final局部变量"复制"一份”
这不是final的理由,因为从编译实现上,当普通局部变量传给匿名类的时候同样可以“复制”。
其实就是传给匿名类的构造方法,使方法中的局部变量和匿名类中同时拥有这个对象的引用。
但真正的原因就在这里,当外面的方法重新赋值的时候,不影响内部类的句柄指向那个对象,
即外部的变量指向A而匿名类的变量却指向B了,这才是不能接受的结果。
因为从源程序上看它们是同一变量。
#5
答:第6点中的一句话:当变量是final时...,.语义效果相同.(
若:不是final,就无法保证:复制品与原始变量保持一致了,因为:在方法中改的是原始变量,而局部内部类中改的是复制品)
#6
你的回答完全是因果倒置的。
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对象是同一的,否则两者任一重新赋值,都会造成它们指向不同的对象。而不是“当变量是final时将变量复制”
不是因为是final就会复制,是因为需要复制才需要final!
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对象是同一的,否则两者任一重新赋值,都会造成它们指向不同的对象。而不是“当变量是final时将变量复制”
不是因为是final就会复制,是因为需要复制才需要final!
#7
进来看看~
#8
路过。。。。 轻轻的
#9
答:恰恰相反.正是目前的所谓的 这个实现技术的缺陷造成的.是因为 在内部类对象中, 没有好的办法去访问 使用方法运行栈中的局部变量,才想出这个笨的方法:将局部变量做一个"复制品"来让内部类对象访问使用.这样: 带来的问题是:如何保证:复制品与原始变量保持一致. final下正是用于这个语义上的 保持一致的.这一点, 我的贴子上已讲得十分清楚了.
对于局部变量int i=3;方法中代码 修改的是这个真正的变量i,而内部为对象修改的是i的复制品copy_i,这样 这两个i就会发生 值的不一致性,(这一点 正是这个实现技术的缺陷),所以 干脆就不允许这个int i=3;局部变量发生值的改变!由于不允许改int i的值,所以这 两个int i的值就 始终保持值的一致了,这 才是final的这个规定的由来! 是 一种不得不如此的无奈之举!
不知道你看别人的贴子,都看到了些什么,没弄清楚就哇哇叫.
#10
进来学习的!
#11
mark
#12
mark,学习下
#13
[Quote=引用 9 楼 jiangnaisong 的回复:]
引用 6 楼 axman 的回复:
你的回答完全是因果倒置的。
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对…
[/Quote
你自己说的话自己看不清楚?
“当变量是final时,通过将final局部变量"复制"一份,复制品直接作为局部内部中的数据成员”
自己说的话,是因为变量是final才需要复制吗?
是因为需保持内部类的生命周期才需要复制,然后是为了保证复制品的行为表现一致才需要final,就这点关系自己弄不清楚还振振有词。
引用 6 楼 axman 的回复:
你的回答完全是因果倒置的。
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对…
[/Quote
你自己说的话自己看不清楚?
“当变量是final时,通过将final局部变量"复制"一份,复制品直接作为局部内部中的数据成员”
自己说的话,是因为变量是final才需要复制吗?
是因为需保持内部类的生命周期才需要复制,然后是为了保证复制品的行为表现一致才需要final,就这点关系自己弄不清楚还振振有词。
#14
#15
把问题复杂化了。
#16
jiangnaisong 正解
#17
复制保证生命周期延续,final保证引用一致
#18
#19
复制保证生命周期延续,final保证引用一致,这个解释是合理的!
#20
#1
为了保证内部实现与外在表现的一致性。
具体请看:
http://blog.csdn.net/axman/archive/2006/12/25/1460544.aspx
具体请看:
http://blog.csdn.net/axman/archive/2006/12/25/1460544.aspx
#2
1楼神了,记下来ψ(._. )>
#3
答:
1)从程序设计语言的 理论上: 局部内部类(即:定义在方法中的内部类),由于本身就是在方法内部(可出现在形式参数定义处或者方法体处),因而 访问方法中的局部变量(形式参数或局部变量)是 天经地义的.是很自然的
2)为什么JAVA中要加上一条限制:只能访问final型的局部变量?
3)JAVA语言的编译程序的设计者当然全实现:局部内部类能访问方法中的所有的局部变量(因为:从理论上这是很自然的要求),但是: 编译技术是无法实现的或代价极高.
4)困难在何处? 到底难在哪儿?
局部变量的生命周期与局部内部类的对象的生命周期的不一致性!
5)设方法f被调用,从而在它的调用栈中生成了变量i,此时产生了一个局部内部类对象inner_object,它访问了该局部变量i .当 方法f()运行结束后,局部变量i就已死亡了,不存在了.但:局部内部类对象inner_object还可能一直存在(只能没有人再引用该对象时,它才会死亡),它不会随着方法f()运行结束死亡.这时:出现了 一个"荒唐"结果:局部内部类对象inner_object 要访问一个已不存在的局部变量i!
6)如何才能实现?当变量是final时,通过将 final局部变量"复制"一份,复制品直接作为局部内部中的数据成员.这样:当局部内部类访问局部变量时,其实真正访问的是这个局部变量的"复制品"(即:这个复制品就代表了那个局部变量).因此:当运行栈中的 真正的局部变量死亡时,局部内部类对象仍可以访问局部变量(其实访问的是"复制品"),给人的感觉: 好像是局部变量的"生命期"延长了.
那么: 核心的问题是:怎么才能使得: 访问"复制品"与 访问真正的 原始的局部变量,其 语义效果是一样的呢?
当变量是final时,若是基本数据类型,由于其值不变,因而:其复制品与原始的量是一样.语义效果相同.(若:不是final,就无法保证:复制品与原始变量保持一致了,因为:在 方法中改的是原始变量,而局部内部类中改的是复制品)
当变量是final时,若是引用类型,由于其引用值不变(即:永远指向同一个对象),因而:其复制品与原始的引用变量一样,永远指向同一个对象(由于是final,从而保证:只能指向这个对象,再不能指向其它对象),达到:局部内部类中访问的复制品与方法代码中访问的原始对象,永远都是同一个即:语义效果是一样的. 否则:当方法中改原始变量,而局部内部类中改复制品时,就 无法保证:复制品与原始变量保持一致了(因此:它们原本就应该是同一个变量.)
一句话:这个规定是一种无可奈何.也说明:程序设计语言的 设计是 受到实现技术的限制的.这就是一例. 因为:我就看到不少人都持这种观点:设计与想法是最重要的,实现的技术是无关紧要的,只要你作出设计与规定,都能实现.
#4
6的理由很牵强了。
“当变量是final时,通过将final局部变量"复制"一份”
这不是final的理由,因为从编译实现上,当普通局部变量传给匿名类的时候同样可以“复制”。
其实就是传给匿名类的构造方法,使方法中的局部变量和匿名类中同时拥有这个对象的引用。
但真正的原因就在这里,当外面的方法重新赋值的时候,不影响内部类的句柄指向那个对象,
即外部的变量指向A而匿名类的变量却指向B了,这才是不能接受的结果。
因为从源程序上看它们是同一变量。
“当变量是final时,通过将final局部变量"复制"一份”
这不是final的理由,因为从编译实现上,当普通局部变量传给匿名类的时候同样可以“复制”。
其实就是传给匿名类的构造方法,使方法中的局部变量和匿名类中同时拥有这个对象的引用。
但真正的原因就在这里,当外面的方法重新赋值的时候,不影响内部类的句柄指向那个对象,
即外部的变量指向A而匿名类的变量却指向B了,这才是不能接受的结果。
因为从源程序上看它们是同一变量。
#5
答:第6点中的一句话:当变量是final时...,.语义效果相同.(
若:不是final,就无法保证:复制品与原始变量保持一致了,因为:在方法中改的是原始变量,而局部内部类中改的是复制品)
#6
你的回答完全是因果倒置的。
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对象是同一的,否则两者任一重新赋值,都会造成它们指向不同的对象。而不是“当变量是final时将变量复制”
不是因为是final就会复制,是因为需要复制才需要final!
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对象是同一的,否则两者任一重新赋值,都会造成它们指向不同的对象。而不是“当变量是final时将变量复制”
不是因为是final就会复制,是因为需要复制才需要final!
#7
进来看看~
#8
路过。。。。 轻轻的
#9
答:恰恰相反.正是目前的所谓的 这个实现技术的缺陷造成的.是因为 在内部类对象中, 没有好的办法去访问 使用方法运行栈中的局部变量,才想出这个笨的方法:将局部变量做一个"复制品"来让内部类对象访问使用.这样: 带来的问题是:如何保证:复制品与原始变量保持一致. final下正是用于这个语义上的 保持一致的.这一点, 我的贴子上已讲得十分清楚了.
对于局部变量int i=3;方法中代码 修改的是这个真正的变量i,而内部为对象修改的是i的复制品copy_i,这样 这两个i就会发生 值的不一致性,(这一点 正是这个实现技术的缺陷),所以 干脆就不允许这个int i=3;局部变量发生值的改变!由于不允许改int i的值,所以这 两个int i的值就 始终保持值的一致了,这 才是final的这个规定的由来! 是 一种不得不如此的无奈之举!
不知道你看别人的贴子,都看到了些什么,没弄清楚就哇哇叫.
#10
进来学习的!
#11
mark
#12
mark,学习下
#13
[Quote=引用 9 楼 jiangnaisong 的回复:]
引用 6 楼 axman 的回复:
你的回答完全是因果倒置的。
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对…
[/Quote
你自己说的话自己看不清楚?
“当变量是final时,通过将final局部变量"复制"一份,复制品直接作为局部内部中的数据成员”
自己说的话,是因为变量是final才需要复制吗?
是因为需保持内部类的生命周期才需要复制,然后是为了保证复制品的行为表现一致才需要final,就这点关系自己弄不清楚还振振有词。
引用 6 楼 axman 的回复:
你的回答完全是因果倒置的。
如何实现?
要保证内部类访问外部的方法的局部变量时生命周期,在实现时必须使内部类也持有对那个外部方法中局部变量的引用(复制这个词太含糊),也就是在内部类的方法中也要有一个句柄指向那个对象,这样当外部的方法退出后,内部类自己的句柄还指向那个对象,所以不会被回收。
因为这个原因,才需要final的定义来保证外部方法中的那个句柄和内部类的句柄指向的对…
[/Quote
你自己说的话自己看不清楚?
“当变量是final时,通过将final局部变量"复制"一份,复制品直接作为局部内部中的数据成员”
自己说的话,是因为变量是final才需要复制吗?
是因为需保持内部类的生命周期才需要复制,然后是为了保证复制品的行为表现一致才需要final,就这点关系自己弄不清楚还振振有词。
#14
#15
把问题复杂化了。
#16
jiangnaisong 正解
#17
复制保证生命周期延续,final保证引用一致
#18
#19
复制保证生命周期延续,final保证引用一致,这个解释是合理的!