本文永久链接 – https://tonybai.com/2025/05/17/java-at-30

大家好，我是Tony Bai。我的极客时间《Go进阶课》专栏已经上线，欢迎大家点击链接订阅学习，我们一起在Go语言的道路上共同精进！

Go语言自开源以来，已走过十多个年头。从最初备受瞩目的“Google语言”，到如今在云原生、微服务领域独当一面，Go 凭借其简洁、高效与强大的并发能力，赢得了全球开发者的青睐，正从一个朝气蓬勃的少年”迈向更加成熟稳健的“壮年”。

然而，“成长的烦恼”也随之而来：生态如何持续繁荣？语言如何在保持核心优势与满足新兴需求之间取得平衡？如何应对一波又一波的技术浪潮冲击？

恰逢 Java 语言诞生 30 周年，The New Stack 对 Java 之父 James Gosling 进行了一次深度访谈。我刚接触 Java 时，它才发布 1.5 版本（Tiger），一晃近 20 年，Java 依然是全球最重要的语言之一。这位编程语言界的“老大哥”和它的创造者，其“长寿秘诀”无疑能为“风华正茂”的 Go 语言带来诸多启示。

Gosling 在访谈中分享了 Java 长盛不衰的关键，我提炼了几点，希望能为Go的未来之路提供一些借鉴与思考。

秘诀一：【解决真实问题，而非追逐时髦】—— Go 的初心与未来挑战

• Java 的经验： James Gosling 强调：“Java 从不追求时髦，始终专注于有效解决问题，帮助工程师完成工作。” 这份对实用主义的坚守，是 Java 能够穿越多个技术周期的基石。
• Go 的启示与思考： Go 语言的诞生，正是为了解决当时 C++ 开发的复杂性、Python 等脚本语言的性能瓶颈以及多核时代并发编程的困境。它以大道至简的哲学，直击痛点，迅速在云原生、分布式系统等领域找到了自己的核心价值。

如今，Go 已走过开源的第一个十年，生态日渐成熟。面对 AI 浪潮、不断演进的硬件架构以及更多元化的应用场景，Go 是否还能保持这份“解决真实问题”的初心？未来，Go 需要识别并解决哪些新的、关键的“真实问题”，以巩固和拓展自身的生态位？这是每一个 Gopher 和 Go 社区贡献者都需要思考的。

秘诀二：【尊重用户，死磕向后兼容与可靠性】—— Go 的生命线如何延续？

• Java 的经验： “尊重用户”、“保持向后兼容”、“优先考虑可靠性 (必须每次都TM的能用！)”——Gosling 的这些话掷地有声，道出了 Java 赢得企业信任的关键。
• Go 的启示与思考： Go 语言著名的“Go 1 兼容性承诺”为其赢得了极佳的口碑，让开发者能够放心地升级版本。然而，随着 Go Modules、泛型等重要特性的引入，社区中也出现了一些关于“必要妥协”与“更大收益”的讨论。

当 Go 生态越来越庞大，用户场景越来越复杂时，如何在不牺牲核心稳定性的前提下，引入必要的改进和演化？如何在社区对某些“破坏性但可能带来更大价值”的变革呼声与“向后兼容”的承诺之间找到最佳平衡点？这将持续考验 Go 核心团队的智慧和社区的共识。

秘诀三：【谨慎创新，不轻易破坏核心价值】—— Go 的“简洁”能否持久？

• Java 的经验： 谈及 Lambda、泛型等重要特性时，Gosling 表示：“我从不想加入一个不‘对’的东西。”他坦言确定最佳实现方式的艰难（“最初的90%很容易想出来，但最后10%超级难”）。这种对语言核心价值的审慎态度，避免了 Java 过早地陷入复杂性的泥潭。
• Go 的启示与思考： Go 在引入泛型时，同样经历了长达数年的社区讨论和极其审慎的设计过程，最终才在 Go 1.18 中落地。这种“慢”在某种程度上保证了新特性与 Go 整体设计哲学的融合。

未来，Go 必然会面临更多引入新特性的需求。如何在满足发展需要与保持语言核心的“简洁性”和“工程效率”之间取得平衡，避免语言的“膨胀”和“复杂化”，将是 Go 能否保持其独特魅力的关键。我们是否应该继续推崇“少即是多”？哪些领域的创新是必要的，哪些又是需要警惕的？

秘诀四：【社区是活水之源】—— Go 的生态如何更上一层楼？

• Java 的经验： 即便在 Oracle 的管理下（Gosling 对 Oracle 的评价是“比预想的好，但期望本来就很低”），他也承认社区在 Java 持续发展和创新中扮演了至关重要的角色。
• Go 的启示与思考： Go 拥有一个全球化、充满活力且贡献卓著的社区。从无数优秀的开源项目到各种技术峰会、meetup，社区的力量是 Go 快速成长的重要驱动力。

进入成熟期后，如何进一步赋能社区，形成更强大的合力？例如，在语言特性方面(如更完善的错误处理、更丰富的原生数据结构支持等，虽然泛型已带来一些改善），如何更好地组织和激励社区进行共建？如何让更多的企业和个人开发者参与到 Go 的核心贡献和生态治理中？这将是 Go 能否持续保持创新活力的关键。

秘诀五：【保持清醒的自我定位，警惕技术炒作】—— Go 在浪潮中的定力

• Java 的经验： Gosling 对当前 AI 热潮的一些犀利点评（例如，称其为“自带一桶有毒废料的营销术语”，认为“大部分 AI 投资将化为乌有”，以及 AI 编码工具在复杂项目中“几乎总是会崩溃”）展现了一种宝贵的清醒和批判精神。他认为 AI 更多是“极其复杂的锤子和螺丝刀”，是人类使用的工具，而非取代人类的自主系统。
• Go 的启示与思考： 面对一波又一波的新兴技术浪潮（从区块链到元宇宙，再到如今的生成式 AI），Go 语言需要有清晰的自我认知和战略定力。它在技术栈中的核心价值是什么？最适合解决哪些领域的问题？

Go 在并发处理、网络编程、系统构建方面的优势，使其在云原生、微服务、分布式系统以及 AI 应用的后端基础设施等领域大放异彩。未来，Go 如何在这些领域继续深耕，同时审慎地探索与新兴技术的结合点，而不是被短期热点裹挟，盲目扩张，这将考验 Go 社区的集体智慧。

小结：知易行难，未来可期

James Gosling 的访谈，不仅仅是对 Java 30 年的回顾，更像是一堂浓缩的技术发展史和语言设计哲学课。虽然很多“名言警句”（比如他对某些公司文化的吐槽，或者对过时工具的调侃）非常抓人眼球，但其背后对技术本质的坚守、对用户价值的尊重、以及对行业趋势的冷静洞察，或许才是 Java 能够穿越周期、屹立 30 年的深层原因。

Go 语言，这位“刚刚十多岁的少年”，正处在发展的黄金时期，也面临着成长的关键抉择。借鉴 Java 这位“老大哥”的宝贵经验，或许能帮助 Go 走得更稳、更远。

想更全面了解 James Gosling 的观点和那些有趣的编程往事吗？推荐阅读原文：
Java at 30: The Genius Behind the Code That Changed Tech

聊一聊，聚焦 Go 的未来：

• 你认为当前 Go 语言发展面临的最大挑战是什么（技术层面或生态层面）？
• 借鉴 Java 的经验，你觉得 Go 社区或官方在哪些方面可以做得更好，以确保其长期健康发展？
• 对于 Go 语言的核心价值（如简洁、并发、工程效率），你认为在未来演进中最需要坚守的是什么？

欢迎大家围绕 Go 的未来发展，在评论区分享你的深度思考！如果你觉得这篇文章对你有所启发，也请转发给你身边的 Gopher 朋友们，让我们一起为 Go 的未来出谋划策。

想与我进行更深入的 Go 语言与 AI 技术交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

我们星球见！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/05/16/energy-savings-if-abandon-https

大家好，我是Tony Bai。

如今，当我们浏览网页时，地址栏那把绿色的小锁和 HTTPS 前缀已是司空见惯。从网上银行到个人博客，再到每一个SaaS服务，HTTPS/TLS 加密几乎覆盖了互联网的每一个角落。它像一位忠诚的数字保镖，守护着我们在虚拟世界中的数据安全与隐私。

然而，这位保镖并非“免费服务”。HTTPS/TLS 在带来安全的同时，也无可避免地引入了额外的计算和传输开销，直观感受便是连接速度可能略有减慢，传输数据量也略有增加。而且，随着我们对安全的追求永无止境，为了抵御更强大的计算破解能力，加密算法的密钥长度也在不断增加（例如从 RSA 1024位到2048位甚至更高，ECC 曲线的复杂度也在提升），这无疑进一步加剧了这些开销。

那么，今天我们不妨来做一个大胆的，甚至有些“异想天开”的思想实验：如果在一夜之间，全球所有的网站都决定弃用 HTTPS/TLS，回归到“裸奔”的 HTTP 时代，理论上能为我们的地球节省多少电力呢？

重要声明： 这纯粹是一个思想实验，旨在通过一个极端的假设，引发我们对技术成本（特别是能源成本）和安全效益之间平衡的思考。我们绝非鼓吹放弃 HTTPS/TLS，其在现代互联网安全中的基石地位无可替代。

HTTPS 的“能源账单”：开销源自何方？

要估算节省的电量，首先得理解 HTTPS/TLS 的主要开销在哪里。这些开销主要体现在两个方面：计算开销和数据传输开销。

计算开销 (CPU 的额外负担)

• TLS 握手阶段： 这是计算密集型操作的重灾区。
  • 非对称加密/密钥交换： 如 RSA、Diffie-Hellman 或 ECC (椭圆曲线加密)，用于安全地协商后续通信所用的对称密钥。密钥长度的增加，使得这些运算的计算量呈指数级或更高阶的增长。 例如，一个 RSA 2048 位操作的计算量远超 1024 位。
  • 证书验证： 客户端需要验证服务器证书链的有效性，这涉及到一系列的数字签名验证操作，同样消耗 CPU 资源。
  • 对称密钥生成与哈希计算： 用于生成会话密钥、消息认证码 (MAC) 等。
• 数据传输阶段：
  • 对称加解密： 建立连接后，所有应用数据的传输都需要经过对称加密算法（如 AES）的加密和解密。虽然对称加密比非对称加密快得多，但对于海量数据流，累积的 CPU 开销依然可观。
  • 消息认证码 (MAC) 计算： 为确保数据完整性，需要为每个数据包计算和验证 MAC。

这些计算开销不仅发生在服务器端（数据中心），也发生在每一个发起 HTTPS 请求的客户端设备上（我们的电脑、手机等）。

数据传输开销 (网络带宽的额外占用)

• TLS 握手数据包： 完整的 TLS 握手过程（尤其是在未使用会话复用或 TLS 1.3 的 0-RTT 时）需要多个数据包的往返，这些数据包承载了证书、加密套件协商信息、密钥交换参数等，本身就构成了额外的网络流量。
• TLS 记录层头部： 每个 TLS 记录包都会增加一个小的头部，指明内容类型、版本和长度。
• 填充数据 (Padding)： 某些块加密模式可能需要填充数据以满足块大小要求。

这些额外的字节虽然对单个请求来说可能不多，但考虑到全球互联网的流量规模，累积起来也是一个惊人的数字。这些额外的数据不仅消耗了网络设备（路由器、交换机、基站）的传输和处理电力，也增加了数据中心内部的存储和带宽压力。

尝试量化：一个极度简化的估算

精确计算全球弃用 HTTPS 能节省多少电量几乎是不可能的，因为这涉及到太多动态和难以获取的数据。但我们可以尝试进行一个基于合理假设的粗略数量级估算，目的在于理解其可能的影响范围。

请注意：以下估算高度简化，仅为引发思考，不代表任何精确的科学结论。

• 假设一：全球每日 HTTPS 请求数。 据一些行业报告估计，全球每日的 HTTP(S) 请求量可能达到数百万亿甚至更高。我们不妨取一个相对保守的中间值。
• 假设二：单次 TLS 握手与数据加解密的平均额外能耗。 这取决于多种因素，包括密钥长度、加密算法、硬件加速能力等。我们可以参考一些研究中关于 CPU 执行加密操作的功耗数据，或者服务器因处理 TLS 产生的额外负载百分比。
• 假设三：TLS 协议的平均数据开销。 TLS 握手通常会增加几KB的开销，后续记录层头部等开销相对较小，我们可以估算一个平均的额外数据传输百分比。
• 假设四：全球数据中心和网络基础设施的总能耗。 这同样是一个巨大的数字，数据中心本身就是能源消耗大户。

基于这些高度简化的假设，即使我们只考虑由于 TLS 计算和额外数据传输导致的 全球数据中心电力消耗增加 1%-5% （这已经是一个非常大胆且可能偏低的估计，因为 TLS 的影响是端到端的），考虑到全球数据中心年耗电量已达数百太瓦时 (TWh，1太瓦时=10亿度电) 的量级，这意味着：

理论上，弃用 HTTPS 每年节省的电力可能达到数个乃至数十个太瓦时。

这是什么概念？一个太瓦时的电力，足以供应数十万个普通家庭一年的用电。数十太瓦时，其能源足迹和碳排放影响将是巨大的。

再次强调，这只是一个非常粗略的“思想实验”级别估算。实际情况远比这复杂，例如：

• 现代 CPU 对 AES 等对称加密有硬件指令加速，大大降低了数据传输阶段的加密开销。
• TLS 1.3 显著优化了握手过程，减少了 RTT 和计算量。
• 会话复用技术能避免重复的完整握手。
• CDN 和边缘节点分担了部分 TLS 终结的压力。

但即便如此，考虑到密钥长度持续增加带来的计算压力，以及全球网络流量的爆炸式增长，HTTPS/TLS 的“能源税”依然是一个不容忽视的议题。

安全的代价：我们为何“心甘情愿”支付这笔账单？

既然 HTTPS/TLS 有如此“隐形”的能源成本，为何我们还要坚定不移地推动全网 HTTPS 化呢？

答案不言而喻：安全！

• 数据保密性： 防止敏感信息（如登录凭证、支付信息、个人隐私）在传输过程中被窃听。
• 数据完整性： 确保数据在传输过程中未被篡改。
• 身份认证： 验证通信对方（主要是服务器）的真实身份，防止中间人攻击。

在一个充斥着网络钓鱼、数据泄露、恶意劫持的数字时代，这些安全保障是我们进行在线活动的基础信任。与可能遭受的经济损失、声誉损害、隐私侵犯相比，HTTPS/TLS 的能源成本可以说是“必要的代价”。

追求平衡：我们能为“绿色安全”做些什么？

这次思想实验的目的，绝非要我们因噎废食，放弃安全。恰恰相反，它应该促使我们更积极地思考：如何在保障同等级别安全的前提下，追求更高的效率和更低的能耗？

1. 持续优化协议与算法： TLS 1.3 就是一个很好的例子(Go标准库crypto/tls已经默认采用TLS 1.3)。未来是否还会有更轻量级、更高性能的安全协议或加密算法出现？
2. 硬件加速的普及： 推动和利用 CPU、专用加密芯片对加密运算的硬件加速能力。
3. 智能的会话管理： 更有效地利用会话复用、0-RTT 等技术，减少不必要的握手开销。
4. 内容分发与边缘计算的优化： 在离用户更近的地方进行 TLS 终结，减少长距离加密传输的开销。
5. 代码层面的优化： 对于应用开发者，合理设计 API，避免不必要的加密数据传输，选择合适的加密库和配置。
6. 关注“适度安全”： 对于某些内部系统或低风险场景，是否可以采用与公网不同强度的、但依然安全的加密策略？（这需要非常谨慎的评估）。

小结：思想实验的价值在于警醒与前瞻

“如果全球网站弃用 HTTPS，能为地球节省多少电？” 这个问题的答案可能永远无法精确计算，但它像一面镜子，照见了我们为构建一个更安全的数字世界所付出的“隐形成本”之一。

这提醒我们，安全并非没有代价，技术进步需要在多个维度上寻求平衡。 在坚定不移地拥抱和强化网络安全的同时，我们也应该持续关注其对性能、资源和环境的影响，积极探索和实践更绿色、更高效的安全技术。

聊一聊，也帮个忙：

• 在你的日常工作中，是否感受过 HTTPS/TLS 带来的性能或资源开销？你是如何应对的？
• 对于未来网络安全技术的发展，你认为在“更安全”与“更高效/更绿色”之间，我们应该如何权衡？
• 除了电力消耗，你认为 HTTPS/TLS 还带来了哪些“隐性”成本或效益？

欢迎在评论区留下你的思考和问题。如果你觉得这篇文章提供了一个有趣的视角，也请转发给你身边的朋友和同事，一起参与这个“思想实验”！

想与我进行更深入的 Go 语言、网络安全与 AI 技术交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

我们星球见！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。