标签：p1 LinkedList next 源码 https prev com final
源码中出现final的地方
- 所有的link有关的方法（增删操作）add remove
- 需要保存中间变量的节点（prev和next指针需要修改的节点）
- 像clear get这种不涉及“更改指针指向”的方法不需要对中间变量定义final
final的作用
LinkedList中Node是一个对象，因此适用于第二条引用数据类型，举个例子：
有无final修饰的浅拷贝
People p1 = new People(18,"张三");
People p2 = p1;
-
当：p1 = null;或者p1 = new People(20,“李四”);
实际上是栈中的p1存储的地址改变，但堆空间中之前 new People(18,“张三”);的对象仍然存在。因此p2不受影响 -
当：p1.setAge(21); 此时操作的是堆空间中的唯一对象，p2会受到影响
在源码中：
final E element = x.item;
final Node<E> next = x.next;
final Node<E> prev = x.prev;
使得element next prev三个属性栈空间保存的地址不可再被重定向，但可以修改值，例如：next.prev = prev和prev.next=next 可以对栈所指向的堆成员变量进行修改
使用final初始化的优点
参考链接：
https://www.cnblogs.com/noteless/p/10416678.html
https://www.cnblogs.com/noteless/p/10410368.html
https://www.cnblogs.com/mianlaoshu/articles/3648403.html
https://www.cnblogs.com/maxiaopao/p/9212903.html
https://zhuanlan.zhihu.com/p/88775601
https://www.zhihu.com/question/21762917/answer/19239387
第四条链接中讲final的优点很详细
第五条讲到了重排序
第六条是JVM对方法中的final变量性能调优
安全性分析
- LinkedList本身是不安全，但这并不影响，因为每次事务初始化的都不是同一个Node对象，如果多线程并发并同时add，那么即便是源码定义了final，也可能会出现错误，因此LinkedList在并发场景下需要自行同步
- 但多线程并发对于方法中局部变量是不存在冲突的
- 排除安全性的可能
性能分析
- 在能够通过编译的前提下，无论局部变量声明时带不带final关键字修饰，对其访问的效率都一样。
- 既然一样，那性能上没影响了。排除
规范
参考阿里巴巴的开发手册
不允许修改的局部变量声明为final更多的是一种规范，在实质作用上加与不加没有区别，但他就是个规范。排除任何可能对这个变量进行修改的可能性
本问题花了我14个小时，查阅了无数资料，问了无数的人，最后能总结出来的答案就是：规范
hhhh浪费了我一天的宝贵时间
总结
- 方法内部初始化的final变量是局部变量
- 没有多线程冲突问题
- 局部静态基本数据变量定义final才有JVM优化，而引用类型则没有
- final可以避免误操作可能带来的问题，因此对所有不会修改的局部变量都用final定义
- LikedList仍然是线程不安全的，需要手动上锁
标签：p1,LinkedList,next,源码,https,prev,com,final 来源： https://blog.csdn.net/m0_56079407/article/details/123034771
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。