前言：阅读一篇技术文章，畅聊一个技术话题。本期文章推荐的是《你背的“八股文”可能已经过时了》。
随着技术的不断更新迭代，一些曾经被认为是“标准答案”的观点和方法，已经不再适应当前的需求，甚至被视为过时的做法。在新的JDK版本中，许多新的特性、工具和方法被引入，使得Java编程变得更加简洁、高效和强大。所以，是时候对“八股文”进行一次知识库的清理和更新了。
本期话题：
1、你知道偏向锁已经被废弃了吗？谈谈你对此的看法。
2、你的“八股文”知识库上次更新是什么时候？印象最深的是哪一条？
（可选择作答）
本期奖励：
截止2023年12月24日24时，参与本期话题讨论，将会选出 2 名幸运用户和 2 个优质回答分别获得阿里云开发者公牛圆盘充电插座一个。快来参加讨论吧～
幸运用户获奖规则：中奖楼层百分比为35%、75%的有效留言用户可获得互动幸运奖。如:活动结束后，回复为100层，则获奖楼层为 100✖35%=35，依此类推，即第75位回答用户获奖。如遇非整数，则向后取整。
如:回复楼层为81层，则81✖35%=28.35，则第29楼获奖。
优质讨论获奖规则：不视字数多，结合自己的真实经历分享，非 AI 生成。
未获得实物礼品的参与者将有机会获得 10-200 积分的奖励。
注:楼层需为有效回答(符合互动主题)，灌水/复制回答将自动顺延至下一层。如有复制抄袭、不当言论等回答将不予发奖。阿里云开发者社区有权对回答进行删除。获奖名单将于活动结束后5个工作日内公布，奖品将于7个工作日内进行发放,节假日顺延。
获奖公告：
截止到12月24日共收到107条有效回复，获奖用户为：
优质回答：算精通、周周的奇妙编程
幸运用户：ZPY0821、wldffg
恭喜以上用户！感谢大家对本话题的支持～
以下为热心网友提供的参考意见
前言
随着互联网技术的不断更新迭代，曾经被认为是“标准答案”的观点和方法已经逐渐失去适应当前需求的能力，甚至被视为过时的做法。就拿最近的技术圈新闻来讲，在新的JDK版本中，Java编程引入了许多新的特性、工具和方法，使其变得更加简洁、高效和强大，但是之前的旧特性和方法也有许多被废弃了，比如曾经比较经典的偏向锁已经被废弃了，因此，个人觉得是时候对“八股文”进行一次知识库的清理和更新了。那么本文就来分享一下关于偏向锁被废弃以及个人对此的看法，并回顾一下自己的“八股文”知识库，以及技术更新迭代地时候我们要保持及时更新自己的知识储备。
《你背的“八股文”可能已经过时了》读后感
在开始本文的话题之前，先来分享一下关于我读《你背的“八股文”可能已经过时了》这篇文章的读后心得体会，这篇文章深入探讨了传统的学习方式在技术领域可能已经不再适用的问题，也让我对技术学习和职业发展的新的思考。我记得文章中指出，过去的技术学习往往以背诵和机械应用为主导，这种“八股文”式的学习方法在今天的快速变革的技术领域已经不再有效，随着技术的不断演进和创新，我们需要培养的是批判性思维、问题解决能力和持续学习的心态。
我非常认同文章中提到的批判性思维的重要性，在面对技术问题时，我们不能仅仅依赖于既定的套路和解决方案，而是需要有能力质疑和挑战现有的观点和做法，在通过思考问题的本质，我们可以更好地理解技术背后的原理和逻辑，并能够提出创新的解决方案。而且文中强调了问题解决能力的培养，因为在现实世界中，技术问题往往是复杂的、多样的，没有一种通用的解决方法，所以我们需要学会分析和拆解问题，掌握基本的解决思路和方法，并能够灵活地运用它们来解决不同的问题，这种问题解决能力的培养需要不断的实践和经验积累。还有就是对于技术人员而言，持续学习的心态至关重要，因为技术领域的变化非常迅速，新技术和新概念层出不穷，只有保持持续学习的心态，不断更新知识，才能跟上行业的发展步伐。
关于偏向锁已经被废弃这件事
看了官方消息，在新的JDK版本中，偏向锁已经被废弃。做Java开发的读者想必都知道偏向锁是一种JVM优化技术，旨在减少无竞争情况下的同步操作的开销。但是随着现代处理器的发展和多核心架构的普及，偏向锁的效果逐渐减弱甚至变得无效，所以Java开发团队决定废弃偏向锁，以便更好地适应当前的硬件环境和多线程编程需求。关于偏向锁被废弃这件事我个人是知道的，而且还知道的比较早。
个人而言，我比较认同官方关于废弃偏向锁的操作，因为技术的发展永远在不断前进，我们需要及时放弃过时的方法，接纳和适应新的技术进展，在废弃偏向锁并引入更适应现代硬件的机制，可以提高多线程程序的性能和可靠性。这也告诉我们每一位程序员，在技术领域，我们应该时刻持续学习和关注最新的发展，及时更新自己的知识储备，只有这样才能与时俱进。
个人“八股文”知识库的更新与印象深刻的知识点
不用多说，对于开发者而言，每个开发者都有属于自己的“八股文”知识库，这些是我们在学习和实际开发中反复使用和总结的知识点和经典模式，但是频繁的技术更新要求作为开发者的我们不断更新我们的知识库，从而适应新的需求、知识和使用工具等。
最近一次我对自己的“八股文”知识库进行更新是在半年前，我在实际使用中发现一些之前被认为是标准的方法和最佳实践已经不再适用于当前的开发环境和场景，所以我开始主动去学习和摸索新的知识点的特性和工具使用，比如Java 14中引入的Switch表达式、Records和Pattern Matching等，这都是之前自己所不具备的知识储备范畴。
在我自己的“八股文”知识库中，最印象深刻的一条是关于代码优化和性能调优的原则，因为在过去我经常依赖一些固定的优化技巧，比如避免使用String的”+”操作符连接字符串、避免在循环中频繁创建对象等“常识”，但是随着JVM和编译器的优化能力的不断提升，一些过去的优化建议和使用“常识”已经不再适用，甚至可能会产生反效果，所以我开始着重通过使用工具进行性能分析和使用合适的算法和数据结构来解决性能问题。
结束语
上文的介绍，关于技术的不断更新迭代使得一些过去被认为是“标准答案”的观点和方法变得过时，尤其是在Java编程领域，新的JDK版本引入了许多简洁、高效和强大的特性、工具和方法，对于我们开发者自己的个人“八股文”知识库，需要定期进行清理和更新，从而适应当前的需求和技术发展。废弃偏向锁就是一个很好的例子，对于个人而言来说，我支持废弃偏向锁的决定，因为面对技术的不断进步，我们就应该及时放弃过时的方法，接纳和适应新的技术进展。而且在技术领域，持续的学习和更新是至关重要的，我们应该保持开放的心态，关注最新的技术动态，并不断更新完善自己的知识储备，只有这样，我们才能在快速发展的技术领域中保持自我竞争力，不断提升自己的技术水平。
以下为热心网友提供的参考意见
偏向锁从jdk15开始被废弃了，新的特性越来越好用时，过时的应该也要放下了。
以下为热心网友提供的参考意见
1、引言
这篇《你背的“八股文”可能已经过时了》我在阿里云的技术公众号看过，
- 当时给我的第一印象：总结的很到位。
- 也给我第一感触：技术更新迭代确实很快。
没想到，社区话题会针对这篇的部分内容进行讨论。 想到了，也没想到。
不管咋样，还是基于这个话题，来聊一聊我自己的一些感触有想法。
2、偏向锁被废弃
我们先来看下， 偏向锁何时被启用：
- JDK 15版本的发布，Java中的偏向锁已经被标记为“过时”（Deprecated）,也就是2020年9月15日。
不知道是否还记得这一天，反正，当时我看到这个消息后，还是很快接受的。毕竟，技术更新迭代是必然的，无法改变，那就顺其自然，坦然接受。
其实，偏向锁被弃用，并非坏事，当然，我相信还有很多Java 技术er，还”沉迷于” JDK 8，这当然也包含我了， 无法舍弃，根本放不下ta。
接下来，我就从2个维度来说一下我自己的一些见解；
-
偏向锁的优点
我能想到的，无非以下这两种，如果你想到更多的，欢迎在评论区补充：- 减少无竞争情况下的锁获取操作，提高性能。
- 减少了线程在获取锁时的阻塞和唤醒操作，降低了线程切换的开销
-
使用偏向锁原因
同样， 我能想到的也是以下这几点：- 习惯：作为一名java老鸟，写了这么多年的BUG，已经习惯了。
- 经验：职业Java老鸟，使用偏向锁写了这么多年BUG，已经熟练掌握偏向锁使用的技巧。
- 特定场景需求： 根据不同的业务，不同的需求，不同的场景，偏向锁还是有必要用一用的，例如：在某些低竞争的场景下，偏向锁可以提高性能，从而给用户/客户一种高性能产品的感觉。
说到这，看的都是偏向锁的优点，既然那么多优点，为何还要被弃用呢？
这就如我开篇所说，技术的更新迭代，无法满足当前的产品/场景的需求。
就如：高竞争场景，多线程弃用，此时，偏向锁的优势反而变为劣势，降低了性能。
所以，任何时候，技术的更新迭代，都是必然性，
这就是一直在唠叨的：持续学习，完善自我。
希望每个技术er都有持续学习的能力，完善自我的技术瓶颈，成为技术大牛。
以下为热心网友提供的参考意见
在Java的并发编程中，有许多种锁机制，包括乐观锁、悲观锁、自旋锁等。其中，偏向锁是一种轻量级的锁机制，它的主要目的是减少无竞争情况下的性能开销。然而，在最新的Java版本中，偏向锁已经被废弃了。
首先，我们需要理解什么是偏向锁。在多线程环境下，当多个线程访问同一个对象时，如果这个对象没有被任何线程锁定，那么第一个获取该对象锁的线程会将对象头中的锁标志位设置为偏向模式，并将自己的线程ID记录在对象的头部。这样，当这个线程再次尝试获取这个对象的锁时，就可以避免进行不必要的CAS操作，从而提高性能。
然而，偏向锁也有其局限性。一旦有其他线程尝试获取这个对象的锁，那么就需要撤销偏向锁，这个过程是非常耗时的。而且，偏向锁只适用于只有一个线程频繁访问某个对象的情况，如果有多个线程频繁访问同一个对象，那么偏向锁就会失去优势。
因此，在最新的Java版本中，开发团队决定废弃偏向锁。这是因为，随着硬件的发展，处理器的速度越来越快，而内存和磁盘的读写速度却没有显著提高，这就导致了CPU和内存之间的速度差距越来越大。在这种情况下，使用偏向锁虽然可以减少一些CAS操作，但撤销偏向锁的过程却非常耗时，反而可能会降低系统的整体性能。
另外，现在的系统通常都是多核的，这意味着即使没有锁的竞争，多个线程也可以同时运行在不同的核心上。在这种情况下，使用偏向锁的意义就不大了。
以下为热心网友提供的参考意见
1、你知道偏向锁已经被废弃了吗？谈谈你对此的看法。
不查不知道，一查吓一跳。Java在JDK 15中废弃了偏向锁。这一决定是在JEP 374（Disable and Deprecate Biased Locking）提案中提出的，并且最终被实施。
偏向锁是一种优化策略，它假设大多数情况下，一个锁总是由同一个线程持有，因此只需要很少的同步开销就可以维护线程安全。为了实现这一点，当一个线程首次获得锁时，该锁会被标记为“偏向”这个线程。后续如果还是这个线程尝试获取锁，那么就可以跳过一些锁定和解锁的步骤，从而提高性能。
然而，偏向锁也有一些缺点。首先，它引入了大量的复杂性到Java虚拟机（JVM）的同步子系统中。这不仅使得JVM的代码更难理解和维护，还可能导致其他方面的性能下降。其次，随着多核处理器的发展和并发编程技术的进步，现代Java应用往往更加倾向于使用非阻塞的数据结构和算法，以及更高级别的并发工具，如java.util.concurrent包提供的类。这些技术通常不需要频繁地使用synchronized关键字，这就降低了偏向锁带来的潜在好处。
此外，偏向锁并不总是能带来性能提升。例如，在高并发场景下，当锁经常在多个线程之间切换时，偏向锁反而会增加额外的开销，因为它需要不断地重置偏向状态。
我认为Java团队废弃偏向锁是一个合理的决策。尽管偏向锁在过去可能对某些类型的程序有所帮助，但随着时间的推移和技术的发展，它的优势已经不再明显，而其带来的复杂性和潜在的性能问题则变得更为突出。通过移除偏向锁，Java可以简化JVM的内部实现，并专注于改进那些对现代应用程序更有价值的特性。
2、你的“八股文”知识库上次更新是什么时候？印象最深的是哪一条？
上一次看Java八股文还是18,19年吧，毕业现在去搞运维了，接触Java也接触的少了。当时背的那些说实话也是似懂非懂，如Java基础、多线程、JVM、数据库等。印象最深的一条是这一条，当时说什么是热点基础问题，考官必考的，哈哈。
以下为热心网友提供的参考意见
1、你知道偏向锁已经被废弃了吗？谈谈你对此的看法。
jdk15的时候提出撤销，也可以理解，相对来说，随着技术的进步，应用会越来越庞大，而且业务随之也会越来越复杂，会有更好的解决高并发情况性能问题的方案产生，所以偏向锁被废弃是必然的。例如Hashtable和Vector，这些程序在每次访问时都会进行同步，数据量大起来的时候是很要命的。我还是挺赞成的。
2、你的“八股文”知识库上次更新是什么时候？印象最深的是哪一条？
上次更新还是工作中遇到问题，主要是业务复杂了。逻辑也麻烦了，就会产生关联的bug。最深的就是采用Java8的时候，相对改动较大，与1.6版本相比，删掉了rt.jar这个包，很多代码就报错了。
以下为热心网友提供的参考意见
1、你知道偏向锁已经被废弃了吗？谈谈你对此的看法。
偏向锁是Java中synchronized关键字的一种优化手段，基本思想是同一个线程的反复访问无需加锁，主要目标是消除数据在没有竞争的情况下的同步操作，提高运行时性能。实际执行时，如果一个线程获得了锁，那么锁就进入偏向模式，此时记录下线程ID，当这个线程再次请求锁时，无需再做任何同步操作，这样就省去了大量有关锁申请的操作。
但是在真实情况中，偏向锁并不总能带来预期的性能优势，相反地，在某些情况下比如多核处理器环境，偏向锁的撤销需要进入全局安全点（即safepoint，虚拟机将所有的线程暂停执行），会带来比较长的停顿时间。偏向锁想法是好的，但是增加了JVM的复杂性，同时也并没有为所有应用都带来性能提升。因此，在JDK15中，偏向锁被默认关闭，在JDK18中，偏向锁已经被彻底废弃（无法通过命令行打开）。
Java社区这个决定这是基于对现代应用并发特性的重新评估。在多核处理器和高并发应用日益普及的背景下，偏向锁的优势可能不如预期显著，而其复杂性可能带来更多的维护成本和潜在的性能问题。
2、你的“八股文”知识库上次更新是什么时候？印象最深的是哪一条？
我的“八股文”知识库上次更新大约是是Java 18发布之后，在Java 18中，最重要的新特性之一是密封类（Sealed Classes）。密封类允许开发者定义类和接口，以限制哪些其他类或接口可以扩展或实现它们。这一特性增强了Java在模型不可变性和严格控制的层级结构方面的能力，提高了代码的安全性和可维护性。通过指定哪些类可以扩展或实现一个密封类，开发者可以确保在应用程序中实现更可预测的行为和更紧密的封装。这个特性在需要一组已知子类的情况下特别有用，例如在域建模或创建一组封闭的操作或类型时。
public sealed interface Shape permits Circle, Rectangle {
double area();
}
public final class Circle implements Shape {
private final double radius;
public Circle(double radius) {
this.radius = radius;
}
@Override
public double area() {
return Math.PI * radius * radius;
}
}
public final class Rectangle implements Shape {
private final double length;
private final double width;
public Rectangle(double length, double width) {
this.length = length;
this.width = width;
}
@Override
public double area() {
return length * width;
}
}
首先定义了一个密封接口Shape，它只允许被Circle和Rectangle两个类实现。Shape接口定义了一个area方法，用于计算面积。
然后，创建了两个最终类Circle和Rectangle，分别实现Shape接口。Circle类有一个属性radius（半径），并重写了area方法来计算圆的面积。Rectangle类有两个属性length（长度）和width（宽度），也重写了area方法来计算矩形的面积。
这个设计确保了实现Shape接口的类集是已知且封闭的，这对于确保类型安全和可预测的行为非常有用
以下为热心网友提供的参考意见
1、你知道偏向锁已经被废弃了吗？谈谈你对此的看法。
是的，偏向锁从JDK1.6开始引入的针对synchronized的锁优化技术，旨在减少无竞争锁定时的开销。但是，随着时代的发展，这一特性在JDK15版本中被官方标记为废弃状态。尽管曾经是一种有效的优化手段，但偏向锁并不总是能够带来预期的性能优势，反而在某些情况下会导致比较长的停顿时间。所以，到了JDK18版本，偏向锁已经被彻底废弃，无法通过命令行打开。这是由于偏向锁的实现复杂，并且会侵入其他HotSpot组件，增加了维护成本和风险。而且，随着硬件性能的提升，偏向锁带来的性能提升现在看起来已经不那么明显了。
2、你的“八股文”知识库上次更新是什么时候？印象最深的是哪一条？
大概是20年吧，印象最深就是python 3.8不再支持2.7的代码。某些功能要用到3.8，但是现有的代码大部分是2.7。这是艰难。回顾python的迭代史
Python 3.8版本是该编程语言的一个重要更新，其中最显著的变化之一就是删除了对Python 2.7的支持。这一举措旨在推动开发者转向使用更现代的Python 3.x版本，以获得更好的性能、安全性和兼容性。但是，Python 2.7自2015年发布以来，已经走过了近十年的历程。虽然它仍然被广泛使用，但随着技术的发展和市场需求的变化，Python社区认为现在是时候放弃对Python 2.7的支持，以便更好地专注于开发和维护Python 3.x版本。
对于仍在使用Python 2.7的我们来说，升级到Python 3.x可能是一个挑战。然而，Python 3.x版本提供了许多新功能和改进，例如更简洁的语法、更好的性能和更广泛的标准库支持等。此外，许多流行的第三方库和框架也已经支持Python 3.x，因此升级将有助于提高代码的可维护性和可扩展性。在Python 3.8中，除了删除对Python 2.7的支持外，还引入了一些其他重要变化。例如，字典对象的插入顺序得到了优化，现在可以直接使用赋值语句进行字典合并。此外，该版本还增加了对f-strings的支持，这是一种新的字符串格式化方法，可以简化代码并提高可读性。
对于那些仍在使用Python 2.7的开发者来说，重写是个大挑战。
以下为热心网友提供的参考意见
我知道Java中的偏向锁在JDK 15中已经被废弃了。这是一项长期的技术决策，背后的原因包括：
-
性能优化：
- 在多线程环境下，随着竞争条件的增加，偏向锁不再提供显著的性能优势。
- 更现代的并发控制技术，如锁消除、锁粗化和适应性自旋等，已经能够更有效地处理同步问题。
-
维护成本：
- 偏向锁是一个相对复杂的实现，需要对每个对象头进行特殊标记，并且必须维护一个额外的数据结构来跟踪偏向的线程。
- 维护这样的复杂性增加了JVM开发者的负担，并可能导致潜在的错误或不一致性。
-
用户行为变化：
- 随着硬件的发展和软件设计模式的变化，用户对于高并发环境下的性能需求也在发生变化。
- 现代应用程序往往更加注重并行性和响应性，而不是简单的单线程效率。
我的看法是，虽然偏向锁曾经是一种有效的性能优化手段，但随着技术的进步，它的重要性正在下降。在许多情况下，其他并发控制技术可以更好地满足现代应用程序的需求。考虑到维护成本和可能引入的复杂性，我认为废弃偏向锁是一个明智的选择。这可以让JVM开发者将精力集中在更有价值的功能上，以提高整个平台的性能和稳定性。
最近一次提到八股文是在2023年1月24日，讨论了它在中国历史上的作用和影响。在2022年11月29日，提到了现代科技面试中的“八股文”。
印象最深的一条可能是“互联网八股文”，因为它反映了在当今的互联网行业中，许多求职者和从业者都会遇到类似的面试问题和挑战。这种现象也被称为“面试八股文”，表明一些技术职位的面试问题具有一定的模式化。对于求职者来说，了解这些常见的面试题目并提前做好准备是很有帮助的。
以下为热心网友提供的参考意见
是的，我了解到Java 15中已经废弃了偏向锁（Biased Locking）。偏向锁是一种Java虚拟机（JVM）在处理多线程并发时的一种优化手段。它的基本思想是在大多数情况下，只有一个线程会访问特定对象的同步代码块，因此没有必要进行重入锁定等复杂的操作。
当没有竞争发生时，JVM会为对象设置一个偏向锁，指向当前正在访问该对象的线程。这样，当这个线程再次访问该对象时，就可以避免很多同步操作，从而提高性能。如果有其他线程尝试访问已经被偏向锁保护的对象，那么需要撤销偏向锁并升级到轻量级锁或重量级锁，这将带来一定的开销。
偏向锁在早期的Java版本中被引入，当时许多应用中的数据结构都是基于哈希表和向量等容器实现的，这些容器大量使用了synchronized关键字来保证线程安全。在这样的环境下，偏向锁可以有效地提升性能。
随着时间的推移，开发人员开始更多地使用并发友好且线程安全的数据结构，如Java集合框架中的ConcurrentHashMap等。这些数据结构不再依赖于大量的synchronized关键字，使得偏向锁的优势减弱。
维护和管理偏向锁也增加了JVM的复杂性。由于偏向锁的状态转换涉及到撤销、升级等操作，这可能会导致额外的性能损失。考虑到这些因素，Java开发者最终决定在Java 15中废弃偏向锁。
虽然废弃偏向锁可能会影响到一些老旧的应用程序，但对于大多数现代应用程序来说，这应该不会造成显著的影响。并且通过禁用偏向锁，可以简化JVM的实现，并可能降低系统的整体复杂性。
以下为热心网友提供的参考意见
偏向锁是一种用于优化同步的锁机制，它允许一个线程在没有竞争的情况下直接获得锁，而无需进行CAS等操作，从而提高了同步的性能。然而，从JDK 15版本开始，Java中的偏向锁已经被标记为“过时”（Deprecated），并在JDK 16版本中被完全删除，取而代之的是轻量级锁和重量级锁。
这样的改变是因为在实际的应用场景中，偏向锁并不总是能够发挥优势，而且在多线程竞争激烈的情况下，偏向锁反而可能导致性能下降。因此，Java官方决定废弃偏向锁，并将轻量级锁和重量级锁作为默认的同步实现。这一决策是基于实际性能和易用性的考虑，以确保Java的同步机制能够在各种场景下提供最佳的性能和可靠性。
对于这一改变，我认为是合理的。虽然偏向锁在某些情况下可以提高性能，但在多线程竞争激烈的环境下，它的性能优势可能并不明显，甚至可能导致性能下降。而轻量级锁和重量级锁则可以根据实际情况提供更稳定和可靠的性能表现。具体选择哪种锁机制还需要根据具体的应用场景和性能要求进行选择和优化。
偏向锁的废弃是Java官方根据实际性能和易用性考虑做出的决策，我们应该理解和接受这一改变，并根据实际情况选择适合的同步机制。
以下为热心网友提供的参考意见
探讨偏向锁在Java中的应用及其近期的变化。偏向锁作为一种用于优化同步的锁机制，通过允许线程在没有竞争的情况下直接获得锁，避免了一些开销，提高了同步的性能。然而，随着JDK版本的更新，偏向锁在Java中已被废弃，并在JDK 16版本中完全删除，取而代之的是轻量级锁和重量级锁。这一变化的主要原因在于，偏向锁在实际应用中并不总是能够发挥优势，特别是在多线程竞争激烈的情况下，可能导致性能下降。
对于偏向锁被废弃的看法，我认为这是Java语言发展的自然过程。随着技术的不断进步和应用场景的变化，一些特性和机制可能会变得不再适用或者存在更好的替代方案。废弃偏向锁的决定是为了推动Java语言的持续发展和改进，提供更好的同步机制以满足现代应用程序的需求。对于已经习惯使用偏向锁的开发人员来说，这意味着需要适应新的同步机制，确保他们的代码能够在新的Java版本中正确运行。尽管可能带来一些困扰和额外的工作量，但从长远来看，这种变化有助于开发人员编写更高效、更可靠的代码，并充分利用Java语言提供的最新功能和技术。
以下为热心网友提供的参考意见
-
是的，我知道偏向锁在JDK 15中已被官方标记为废弃状态。这个决定可能是出于对代码复杂性和性能优化的综合考虑。虽然偏向锁在特定场景下可能带来性能提升，但在多线程和单线程的不同情境下也存在一些缺陷，可能导致性能下降。对于废弃的决定，我认为是为了简化和优化Java虚拟机的同步机制，使其更适应现代多核处理器等硬件架构的需求。
-
我始终认为及时更新知识库是程序员职业生涯中的一项重要任务。最后一次更新我的“八股文”知识库是在最近的几个月。印象最深刻的一条是关于Java中的Lambda表达式和函数式接口。Lambda表达式的引入使得Java的代码更加简洁和易读，而函数式接口为函数式编程提供了支持。这种编程风格的变革使得我能够更好地利用Java中的新特性，提高代码的表达力和可维护性。
以下为热心网友提供的参考意见
作为一位程序员，我对技术的发展和进步一直保持高度的关注。当我了解到偏向锁已被废弃的消息时，我意识到这是一个重要的转变。
偏向锁是Java中synchronized关键字的一种优化手段，其基本思想是同一个线程的反复访问无需加锁，从而提高运行时性能。然而，在实际的应用环境中，偏向锁并不总是能带来预期的性能优势。特别是在多核处理器环境下，偏向锁的撤销过程可能导致较长时间的停顿，影响系统整体性能。因此，为了更好地适应现代计算机硬件的发展和需求，Oracle公司在 JDK 15 中，默认关闭了偏向锁，并在 JDK 18 中将其彻底废弃。
在我看来，这种改变体现了 Java 开发团队对技术发展趋势的敏锐洞察力以及他们致力于持续改进的决心。虽然偏向锁曾被认为是一种有效的优化手段，但随着硬件环境的变化和技术的进步，我们需要重新审视并调整我们的策略。放弃过时的技术，采用更适合当前环境的新方案，这是软件开发过程中不可避免的一部分。
至于我的“八股文”知识库，我会定期对其进行更新，以确保自己掌握最新的技术和最佳实践。我记得最近一次大规模的更新是在去年，当时我深入研究了 Java 的新特性，其中印象最深的一条就是 Java 可以在接口中定义私有方法。这个改动让我感到非常惊喜，因为它极大地提高了代码的复用性和可维护性，同时也让接口的设计变得更加灵活。
在以往的 Java 版本中，接口的目的是定义公开的 API，而不包含具体的实现细节。然而，随着时间的推移，人们发现接口中的默认方法如果需要共享一些代码段，往往只能将这些代码段抽象成一个新的函数。这样做不仅增加了代码的冗余，而且还可能导致 API 被无意间暴露出去。为此，Java 9 引入了一项重要改进：允许开发者在接口中定义私有方法。
这项改进的意义在于，我们可以更加方便地提取和封装接口中的公共代码，从而降低代码的冗余度，提高代码的可读性和可维护性。此外，由于私有方法不会被外部直接访问，我们也可以放心地在其中使用那些不应对外公开的内部逻辑。
以下为热心网友提供的参考意见
1、你知道偏向锁已经被废弃了吗？谈谈你对此的看法。
偏向锁是从JDK1.6引入的一种针对synchronized的锁优化技术，它的主要目的是假设monitor一直由某个特定线程持有，直到另一个线程尝试获取它，从而避免获取monitor时执行cas的原子操作。 这种优化技术能够减少无竞争锁定时的开销，使得JVM的性能得到了显著改善。
然而，从JDK15开始，偏向锁被官方标记为废弃状态，如果还想继续使用的话需要通过JVM参数手动启用。 这是因为，虽然偏向锁在过去看来能够提升性能，但在现在看来已经不那么明显了。 另外，撤销偏向锁还不能对持有偏向锁的线程有影响，需要等待持有偏向锁的线程到达一个安全点，这个过程可能会增加系统的开销。
对于偏向锁被废弃的看法，我认为这是一个正常的技术迭代过程。随着计算机硬件的发展和JVM优化技术的不断进步，可能会有更高效的锁机制来替代偏向锁。同时，废弃偏向锁也为未来的JVM优化提供了更多的可能性。虽然在短期内，这可能会对一些使用了偏向锁的应用程序造成影响，但从长远来看，这有助于推动Java技术的发展和进步。
2、你的“八股文”知识库上次更新是什么时候？印象最深的是哪一条？
Java在不断更新中带来了一系列的新特性和改进。例如，Java 10的主要更新内容包括局部变量的类型推断、应用类数据共享、向G1引入并行Full GC线程局部管控等。进一步来看，Java 19版本也带来一些重要的更新，包括语言更新和改进上，如JEP 405: 记录模式（预览版） — 支持用户嵌套记录模式和类型模式，以创建强大、声明性且可组合的数据导航和处理形式，从而扩展模式匹配，实现更复杂的数据查询；还有JEP 427: Switch 模式匹配（第三预览版） — 根据某些模式来测试表达式，以进行 switch 表达式和语句的模式匹配，让用户可以安全、简洁地表达面向数据的复杂查询；以及工具类库的更新，如JEP 424: 外部函数和内存 API（预览版） — Java 程序可以更容易地与 Java 运行时之外的代码和数据进行互操作。这些更新不仅提高了Java的性能，还扩展了它的功能，使其更加适应不断变化的技术环境。
以下为热心网友提供的参考意见
偏向锁是一种用于优化同步的锁机制，它允许一个线程在没有竞争的情况下直接获得锁，而无需进行CAS等操作，从而提高了同步的性能。然而，随着JDK版本的更新，偏向锁在Java中已经被废弃，从JDK 16版本开始已经被完全删除，取而代之的是轻量级锁和重量级锁。这种改变的原因在于，偏向锁在实际的应用场景中并不总是能够发挥优势，而且在多线程竞争激烈的情况下，偏向锁反而可能导致性能下降。因此，Java官方决定废弃偏向锁，让轻量级锁和重量级锁作为默认的同步实现。
对于偏向锁被废弃的看法，我认为这是Java语言发展的一个自然过程。随着技术的不断进步和应用场景的不断变化，某些特性和机制可能会变得不再适用或者存在更好的替代方案。在这种情况下，Java官方选择废弃偏向锁是为了推动Java语言的持续发展和改进，同时也是为了提供更好的同步机制来满足现代应用程序的需求。
当然，对于已经习惯了使用偏向锁的开发人员来说，这种改变可能会带来一些困扰和额外的工作量。他们需要重新学习和适应新的同步机制，以确保他们的代码能够在新的Java版本中正确运行。然而，从长远来看，这种改变是有益的，因为它可以帮助开发人员编写更高效、更可靠的代码，并且可以充分利用Java语言提供的最新功能和技术。
以下为热心网友提供的参考意见
- 我知道偏向锁在Java 8u40之后已经被废弃了。我认为这是由于多核处理器和轻量级锁的性能提升所导致的。
偏向锁的初衷是为了减少在没有多线程竞争的情况下锁的消耗，但在实际应用中，由于现代CPU的预读取机制和多核处理器的普及，轻量级锁的开销已经变得非常小。因此，偏向锁的优势并不明显，反而增加了实现的复杂性。所以，废弃偏向锁是一个合理的选择。
- 我的“八股文”知识库上次更新是在Java 8发布的时候。
印象最深的一条是关于Lambda表达式的引入。Lambda表达式使得Java的代码更加简洁，更符合函数式编程的思想。它使得集合操作、异步编程等场景下的代码更加易读和易于维护。同时，它也推动了Java社区对于函数式编程的关注和讨论，促进了Java语言的发展。
以下为热心网友提供的参考意见
Java开发工具包JDK的各个版本在不断的完善和升级。对于“偏向锁被废弃”的问题，我认为这是技术发展和优化的一个必然结果。
随着JDK版本的更新，一些旧的特性和工具可能会被新的、更高效的方法所取代。这种变化可以推动Java编程的进步，使其更加适应现代的开发需求。
至于“八股文”知识库的更新，这需要根据个人的学习和工作情况进行。
如果某个知识点已经不再适应当前的需求或者已经被新的技术取代，那么就需要进行更新。印象最深的一条可能就是“泛型”的引入，它极大地提高了代码的可读性和复用性。
技术的更新换代是无法阻挡的，我们需要不断学习新的知识和技能，以适应这个快速变化的世界。
以下为热心网友提供的参考意见
1、偏向锁已经被废弃，这是Java 9引入的可变参数模式的结果。
偏向锁是一种优化技术，用于在多线程环境下减少锁定的开销。然而，随着Java并发编程模型的发展，偏向锁已经不再是最优的解决方案。在Java 9中，引入了可变参数模式，它可以根据不同的参数类型和数量动态地选择合适的锁，从而在保证线程安全的同时，提高程序的性能。我认为这是一个很好的改进，它使得Java在并发编程方面更加灵活和高效。
偏向锁是一种针对单线程访问的优化手段，主要应用在以下场景：
- 当一个对象被多个线程访问时，如果所有线程都只读取对象的属性，那么偏向锁可以让线程自由地读取对象的属性，而无需进行同步。这样可以提高程序的运行效率。
- 当一个对象被多个线程访问时，如果所有线程都只对对象进行写操作，那么偏向锁可以让线程自由地进行写操作，而无需进行同步。这样也可以提高程序的运行效率。
偏向锁的实现原理是，在对象被创建时，偏向锁会记录一个线程ID，如果后续的访问都是来自这个线程，那么偏向锁就不需要进行同步。只有当其他线程尝试访问这个对象时，偏向锁才会撤销，进入同步状态。
public class偏向锁Demo {
private int value;
private Thread owner;
public void setValue(int value) {
synchronized (this) {
this.value = value;
this.owner = Thread.currentThread();
}
}
public int getValue() {
synchronized (this) {
if (owner == Thread.currentThread()) {
return value;
} else {
throw new RuntimeException("Not allowed");
}
}
}
public static void main(String[] args) {
偏向锁Demo demo = new 偏向锁Demo();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 10; i++) {
demo.setValue(i);
System.out.println("Set value: " + i);
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 10; i++) {
System.out.println("Get value: " + demo.getValue());
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
t1.start();
t2.start();
try {
t1.join();
t2.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
在这个Demo中，我们创建了一个名为偏向锁Demo的类，它有一个int类型的属性value和一个Thread类型的属性owner。setValue方法使用synchronized关键字进行同步，而getValue方法则通过检查owner属性来判断当前线程是否拥有偏向锁，如果是，就直接返回value，否则抛出异常。
在main方法中，我们创建了一个偏向锁Demo的实例，并启动了两个线程，一个用于设置value，一个用于获取value。由于我们使用的是偏向锁，所以这两个线程可以同时运行，不会出现阻塞现象。
2、我的“八股文”知识库是定期更新的，最近一次更新是在2023。每一次更新都会引入新的特性、工具和方法，使得Java编程变得更加简洁、高效和强大。印象最深的是Java 17中引入的垃圾回收器G1的改进。G1是一种面向服务端应用的垃圾回收器，它通过划分多个内存区域，并行地进行垃圾回收，大大提高了垃圾回收的性能。这个特性对于服务端应用的开发者来说非常有价值，它可以帮助我们更好地管理内存，提高应用的性能和响应速度。
Java 17中引入的垃圾回收器G1的改进主要体现在性能和可扩展性方面。G1（Garbage-First）垃圾回收器是一种面向服务端应用的垃圾回收器，它通过划分多个内存区域（Region）并行地进行垃圾回收，从而提高垃圾回收的性能。在Java 17中，G1的改进包括以下几点：
- 减少了G1垃圾回收器在进行垃圾回收过程中的暂停时间。在Java 17中，G1使用了一种名为“并发标记扫描”（Concurrent Mark Sweep，CMS）的算法，该算法可以在垃圾回收过程中减少线程的暂停时间。
- 增加了G1垃圾回收器与其他垃圾回收器（如CMS）的互操作性。在Java 17中，G1可以与其他垃圾回收器（如CMS）更平滑地切换，从而提高系统的稳定性和可扩展性。
- 改进了G1垃圾回收器在低延迟场景下的性能。在Java 17中，G1垃圾回收器引入了一种名为“G1根扫描”（G1 Root Scanning）的技术，该技术可以更快地找到垃圾回收的根对象，从而减少垃圾回收过程中的延迟。
java -XX:+UseG1GC -XX:GCTimeRatio=90 -XX:InitiatingHeapOccupancyPercent=70 -mx4g -jar your_app.jar
参数说明：
- -XX:+UseG1GC：启用G1垃圾回收器。
- -XX:GCTimeRatio=90：设置垃圾回收器暂停时间的上限为90%。
- -XX:InitiatingHeapOccupancyPercent=70：设置初始堆占用率调整为70%。
- -mx4g：设置最大堆内存为4GB。
public class G1Demo {
public static void main(String[] args) {
G1Demo g1Demo = new G1Demo();
g1Demo.testG1();
}
public void testG1() {
int[] arr = new int[10000];
for (int i = 0; i < arr.length; i++) {
arr[i] = i;
}
System.out.println("Array created");
// Do some work with the array
System.out.println("Array used");
gc();
System.out.println("After gc");
}
public void gc() {
System.gc();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
在这个Demo中，我们创建了一个长度为10000的整数数组，并使用System.gc()方法触发垃圾回收。然后，我们通过Thread.sleep(1000)方法等待垃圾回收器完成垃圾回收
以下为热心网友提供的参考意见
我还记得小时候，电脑是我心中的神奇黑匣子，对它充满了好奇和向往。随着年龄的增长，我终于有机会学习计算机科学，并将梦想变为现实。我在大学学到了很多基础知识，其中也包括了那时尚且废弃的“八股文”编程风格。
当时，String类的内部是通过char数组来保存字符数据的，而现在在JDK9以后，它的实现已经内部改为使用byte数组。这种变化让我深感技术的不断进步，对于性能的优化和内存的利用变得更加精准。这让我回想起自己刚刚接触编程时，总是被要求按照固定的格式和套路去写代码，仿佛那是唯一的正确之道。
随着时间的推移，我见证了Java语言的发展，从switch语句只支持基本类型与String到现在支持更多类型的模式匹配，这让我感到编程的世界也在不断演进。曾经被认为是“标准答案”的做法，也在新的JDK版本中逐渐被打破，给程序员更多的自由度。
在我成长的过程中，synchronized关键字的偏向锁曾经是一种被推崇的优化手段，但随着多核处理器的普及，偏向锁的局限性变得越发明显，最终在JDK18中被废弃。这让我思考，技术的进步不是一成不变的，有时候过去的“最佳实践”可能会因为新的环境而失效。
回顾这一路的变革，我意识到技术的发展是不可阻挡的。曾经的“标准答案”可能会过时，曾经的“最佳实践”可能会失效，但每一次的改变都是为了更好地适应当下的需求和挑战。在编程的世界里，我们需要保持学习的心态，不断更新自己的知识库，才能在变革中把握机遇，走得更远。
转转请注明出处：https://www.yunxiaoer.com/177796.html