在正文开始之前，推荐一个我开发的宝藏健身小程序 乐动记 帮助健身爱好者，学习动作，记录和分析训练内容，追踪训练效果！点击下面图片即可使用。
近日，开源界发生了一起令人震惊的事件，全球知名项目 Elasticsearch 的 GitHub 仓库在一夜之间失去了近 7 万个 Star。
Elasticsearch 是一个开源的分布式全文搜索引擎，广泛应用于存储、搜索和分析大量数据。核心功能包括高效全文搜索、实时数据分析和分布式存储。
具体发生了什么事，让全球知名项目 Elasticsearch 竟然跌得比股票还凶，超 7 万 star 的项目star 骤降，一夜之间被瞬间清零。
事情起源于，有网友发现，开源全文搜索引擎 Elasticsearch 位于 GitHub 上仓库的 star 数一夜之间突然骤降，从 7 万到几乎清零。事情被公布出来以后，还有开发者表示访问 GitHub 仓库直接出现 404。
随后，Elasticsearch 团队迅速介入调查并公开回应了此事。
经过调查，问题的根源在于 Elastic 公司内部的一次误操作。在变更操作过程中，工作人员不慎将多个公开 Git 仓库错误地设置为私有。
这一失误操作导致不仅造成了 Star 数量的巨大损失，而且还影响了用户无法访问这些 GitHub 仓库，不仅 Elasticsearch 仓库本身出现了“404”，连 Elastic 公司组织下的其他 GitHub 仓库也受到了牵连。
这里需要普及一下，在 GitHub 如果将原本是 public 状态的 GitHub 仓库设为私有，那该仓库对应的 Watcher 和 Star 数据就会被永久删除。
在发现问题后，Elasticsearch 团队立即采取了行动，紧急恢复了受影响的仓库状态。经过一系列努力，他们成功地将所有仓库重新设置为公开，并恢复了所有分支。
虽然 Elasticsearch 仓库被恢复，然而，Star 数量的损失却成为了无法弥补的遗憾。截止发文前 Elasticsearch 有重新飙升到 1.4k Star。但是和之前比起来相差太远了。
虽然 Elasticsearch 这样的顶级开源项目如今已无需依靠 star 数或 fork 数来彰显其价值，但多年来累积的社区数据一旦归零，无法恢复是一件挺遗憾的事情。。
这些事件给我们敲响了警钟。在使用 GitHub 等在线平台时，我们必须时刻保持警惕，确保每一步操作都准确无误。尤其是在处理公开项目时，更要谨慎行事，以免给项目和社区带来不必要的损失。
Binder事务缓冲区的大小是1MB 吗 为什么使用Bundle而不使用 HashMap ThreadLocal无法在多个线程之间进行上下文信息传递 ThreadLocal 可能会造成数据污染 点击返回键，进程会退出吗 主线程结束了，子线程是否可以正常运行 从字节码看 finally 的本质，你能说出这些代码运行结果吗？ 用final声明的局部变量，能提升性能吗 线程池解决什么问题，为什么不推荐使用Executors创建线程池
👇🏻 真诚推荐你关注我👇🏻
