内存管理，对于C/C++选手来说，是个再熟悉不过的名词。malloc/free，new/delete，一旦使用不当，就会遇到mem leak，uaf，double free等等内存问题。但是对于其他高级语言例如JAVA，JS等，似乎从来不需要关心他们创建对象的死活，是这些语言可以违背计算机的规律么？当然不是，只是这些语言底层的编译器/虚拟机自动对内存进行了管理，我们一般称之为GC(garbage collect)。 GC的历史可以追溯到上世纪50年代，从诞生之初起，它就像一个幕后英雄，默默做着奉献，帮助开发者提高了开发效率。在我看来，GC就像一种内存扩大技术：我们只需要不断的向其索取，而不用担心由于物理内存限制导致的内存问题。对于GC，虽然它能自动管理内存，但是当我们对它了解的越多，越能帮助我们在日常开发工作中提高代码效率。
在App开发过程中，崩溃率是衡量App稳定性的关键指标。因为App崩溃不仅仅影响用户的即时体验，更对用户留存率构成了潜在的威胁。它如同一颗隐形的定时炸弹，随时可能引发用户体验的灾难。App崩溃分为Java Crash和Native Crash 2种。 Native Crash因为其上下文信息不完整、错误提示模糊以及难以捕捉等特性，相比较Java Crash，定位及修复更为棘手困难。作为外卖商家日常运营不可或缺的助手，饿了么商家版APP的用户体验一直是我们团队的首要考量。然而，伴随着业务迭代与设备系统的不断升级，我们的应用Native Crash率上升明显，一度从原先的万2攀升到了万6以上。为此我们启动了Native Crash的专项治理行动，致力于为用户提供一个更加可靠稳定及高效的App应用，让所有商家都能享受到无忧的数字化运营体验。
历时18个月，跨越长三角多个地区，搬迁数万台服务器和交换机设备……B站数据中心圆满完成搬迁项目，新机房拥有更先进的基础设施和更全面的技术支持，将进一步优化上层业务布局，支撑业务整体的异地多活，有效提升资源利用率和运营稳定性，为广大B站用户带来更好的访问服务体验。
在一个平凡的夜晚，当你结束了一天的工作，打开电脑准备开始一场游戏时，随着加载进度条完成，一个虚拟世界呈现在屏幕上。 你沉浸其中，忽见一只蚂蚁缓缓爬过屏幕。刹那间，脑海中浮现起曾读过的小说《三体》，蚂蚁的身影仿佛在提醒你什么，心头不由一紧，寒意袭上。一个念头如同惊雷般闪现——难道我们每个人的一生，乃至这个广袤的世界，都是某个外星高等文明所构建的模拟？
这篇文章主要探讨了如何在阿里云MaxCompute（原ODPS）平台上对SQL任务进行优化，特别是针对大数据处理和分析场景下的性能优化。
在《字节跳动容灾实践：同城容灾+异地多活是最好的模式吗？》一文中，我们介绍了字节跳动从单机房到同城多机房再到异地多活的演进过程。本文将围绕字节跳动当前的模式——同城容灾+异地多活，介绍团队在异地单元化架构落地上的一些思考和实践。
