比较稳定得干了这么多年，谁能想到一年内能处理4起内存泄露问题呢？
第一则比较简单，运营人员操作时遭遇经典弹窗《计算机的内存不足》。打开任务管理查看，未发现高占用的应用程序。
找运维获得管理员账户，打开任务管理器，发现亚信安全杀毒软件进程占用内存最多。运维通过管理后台卸载杀毒软件后恢复正常。
问题反馈软件厂家，厂家调查回复，用户登录时会在右下角弹出软件运行状态窗口，该窗口存在内存泄露问题，假如用户未关闭该窗口，则会一直泄露内存，最终导致内存不足。
因为该问题发生多次，（服务器会有很多登录后不管的session），部分服务器由运维统一卸载该软件以解决问题。
第[……]
迁移本身并不复杂，甚至直接拷贝文件后新建 git 目录也是可行的。若要保留提交历史则可以参考了解如何从 Subversion (SVN) 迁移到 Git（包括历史记录）和官方的迁移到 Git。
现在发行的 windows 版 git 工具已经自带 svn 模块，但实际操作时因为各参考命令的环境不同，需要在 powershell 和 git bash 环境不断来回切换，这一点就比较费力。
对于迁移而言，首先需要一个 svn 用户和 git 用户的转换关系。在powershell 中执行以下语句导出 svn 用户列表，但 Out-File 默认格式是 utf8，git 不支持读取带 B[……]
程序在开发机上借助 IDE 的工具进行性能分析是非常简单的，但在程序在正式环境运行时进行慢函数分析就比较困难。这里介绍2个工具，CVCollectionCmd 和 PerfView，借助它们的力量（性能计数器和其他系统探针）可以对 windows 中运行的 .net 程序进行运行中分析。
CVCollectionCmd 实际是 Visual Studio 的非自带官方扩展——并发可视化工具的独立命令行工具，可以独立于 Visual Studio 运行。除了可以直接 Open 启动一个进程外，还可以 Attach 现有进程。
# 启动 "C:\Program Files (x86)\M[......]
代码地址：https://github.com/HDRorz/WorkDayProject
这个 grpc 在 20 年.net core 3.1 release 时就看到官方最新鲜的文档，就着手开始开发了，依旧以工作日服务这个功能实现了服务器端和客户端。然而开发过程并不是一帆风顺的。
protobuf 默认定义的数据类型中并不包含时间，这令人略感意外，这就需要另外进行处理，引入时间类型，这需要在 proto 文件增加一行引用。
这又带来一个新问题，vs 无法编译这个 proto 文件，在通过一连串莫名其妙的操作后（其实是我已经忘了），项目终于恢复正常。
当然这个时[……]
作为一名中国程序员，甚至只是一名普通用户，编码问题一直困扰着我们的生活。包括 txt 乱码、网页乱码、程序乱码都屡见不鲜，各种“烫烫烫”和“棍斤拷”，还有方块？和莫名繁体。
字符编码相关知识：
常见乱码解决方案：
《常见乱码问题分析[……]
代码地址：https://gist.github.com/HDRorz/761c8850b91bf25d323c40eab9898c91
因为某一天在论坛里突然看到一种上古加密通讯语言：佛曰。至于加密了什么内容，在这里不能说。就想到最近几天搞的数据库连接字符串加密功能里用到的base64 编码。base64 编码用处广泛，可以把字节（0-255）数组转化为 ASCII 码（0-127）中的可显示字符 64 个，这个 8 位 -> 6 位的编码和解码规则简单且万能，常用于邮件（utf-7）、url 和加解密（秘钥和密文存储）。
但是 base64 有个明显的缺点，就是他[……]
首先有一点必须要明确，数据库服务器配置越强，肯定跑的越快。最影响数据库性能的肯定是硬盘，因为数据库的可靠性是靠写入磁盘实现的，由于短板效应，硬盘这个计算机最慢的东西决定了性能。SSD 是高性能最不可缺少的一部分，而且对于 SSD 来说，容量越大，速度越快。对于云主机来说则有一个 IOPS 的指标，在多租户的环境下，云服务提供商提供的虚拟化设备对单机的 IOPS 有固定的限制，会影响性能（当然包括超售）。
第二就是内存，内存影响缓存的大小，假如数据都缓存在内存中，那数据库查询速度肯定是和 Redis 之流是一样的。而且我们使用 Redis 这些内存 kv 数据库的最主要原因[……]
因为公司主力数据库用的Oracle11g，正好我也接受过OCP考试的培训（只考出一门，第二门考不出），用起数据库来还算得心应手。入职四年来，也算弄出过一点数据库事故，特别最近一年因调岗到清算部门，获得了数据库owner的权限，作死的步伐就从未停下。
10年前（200x-2015），感觉说到数据库就是三大哥Oracle、SQL Server 和 MySql，现在 RDMS 则又多了PostgreSQL。差不多2010年后开始流行NoSQL，产生了新三哥MongoDB、Redis 和 Couchbase（Memcached）。过了几年，开始流行大数据，HBase和Hive开[……]
最近在大量把单线程功能改写成多线程，因为作死、弱智等原因，经常写出大量bug，其中调试遇到各种困难，在这里介绍一例未知原因崩溃的排错过程。
如图，在事件管理器中发现程序死于UnhandledException，且未记录抛出异常的代码行号。在毫无头绪的情况下只能在此祭出调试神器windbg。
用 !EEstack 打印所有线程堆栈，找到抛出异常的线程：43号。
用 !PrintException 打印线程中的异常。在一系列的异常套娃中找到抛出异常的地址 000007fe97c01745。
用 !IP2MD 找到方法名和方法地址 000007fe97c918[……]