# 背景 发现陷入了一个怪圈，写文章的话，感觉只有大bug或比较值得写的内容才会写，每次一写就是几千字，争取写得透彻一些，但这样，我也挺费时间，读者也未必有这么多时间看。 我想着，日常遇到的小bug、平时工作中的一些小的心得体会，都还是可以写写，这样也才是最贴近咱们作为一线开发生活的，也不必非得是个
## 背景 最近一组业务redis数据不断增长需要扩容内存，而扩容内存则需要重启云主机，在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障，这里记录分享一下。 ## 业务redis高可用架构 该组业务redis使用的是一主一从，通过sentinel集群实现故障时的自动主
很长一段时间里，我都被困扰着，感觉陷入了笔记的泥潭，而积累的如此多的笔记也没有形成我自己的知识体系。 之前的记笔记方式 笔记的来源 微信公众号 技术博客 纸质书籍 官网文档 PDF 自己的零散想法 网页 之前的笔记软件 有好几个： 为知笔记 浏览器书签 MarkDown 文档 Calibre 电子书
在.Net Framework时代，我们生成验证码大多都是用System.Drawing。 在.Net 6中使用也是没有问题的。 但是，System.Drawing却依赖于Windows GDI+。 为了实现跨平台，我陷入了沉思!! 微软推荐使用SkiaSharp 进行替代，所以就开始了，踩坑之旅
进程间通信 1.什么是通信 数据传输：一个进程需要将自己的数据传输给另一个进程 资源共享：多个进程同时共享一个资源 进程事件：一个进程向一组（或一个）进程通知某一事件，如：子进程结束要通知父进程来回收资源 进程控制:有些进程需要知道另一个进程的状态，控制拦截另一个进程陷入异常等，如：gdb调试 2.
协程不是系统级线程，很多时候协程被称为“轻量级线程”、“微线程”、“纤程(fiber)”等。简单来说可以认为协程是线程里不同的函数，这些函数之间可以相互快速切换。 协程和用户态线程非常接近，用户态线程之间的切换不需要陷入内核，但部分操作系统中用户态线程的切换需要内核态线程的辅助。 协程是编程语言（或
在学习 Spring 框架源码时，记住一句话：源码并不难，只需要给你各种业务场景或者项目经理，你也能实现自己的 Spring。虽然你的实现可能无法与开源团队相媲美，但是你肯定可以实现一个 0.0.1 版本。因此，初次阅读源码时，不要陷入太深的细节中,先了解大体逻辑，再仔细研读。
# React闭包陷阱 `React Hooks`是`React 16.8`引入的一个新特性，其出现让`React`的函数组件也能够拥有状态和生命周期方法，其优势在于可以让我们在不编写类组件的情况下，更细粒度地复用状态逻辑和副作用代码，但是同时也带来了额外的心智负担，闭包陷阱就是其中之一。 ## 闭
最近网上冲浪的时候看到有人分享了自己最近一次性能优化的经验。我向来对性能是比较敏感的，所以就点进去看了。 然而我越看越觉得蹊跷，但本着“性能问题和性能优化要靠性能测试做依据”，我不能凭空怀疑别人吧，所以我做了完整的测试并写下了这篇文章。 可疑的优化方案 分享者遇到的问题很简单：他发现程序中超过一半的
本文从一例业务中遇到的问题出发，以FLAG_ACTIVITY_NEW_TASK这一flag作为切入点，带大家探究Activity启动前的一项重要的工作——栈校验。文中列举一系列业务中可能遇到的异常状况，详细描述了使用FLAG_ACTIVITY_NEW_TASK时可能遇到的“坑”，并从源码中探究其根源。只有合理使用flag、launchMode，才能避免因为栈机制的特殊性，导致一系列与预期不符的启动
简介 自从JDK中引入了stream之后，仿佛一切都变得很简单，根据stream提供的各种方法，如map，peek，flatmap等等，让我们的编程变得更美好。 事实上，我也经常在项目中看到有些小伙伴会经常使用peek来进行一些业务逻辑处理。 那么既然JDK文档中说peek方法主要是在调试的情况下使
> 本文的知识点其实由golang知名的for循环陷阱发散而来， 对应到我的主力语言C#， 其实牵涉到闭包、foreach。为了便于理解，我重新组织了语言，以倒叙结构行文。 先给大家提炼出一个C#题：观察for、foreach闭包的差异 