由于 go 原生支持了交叉编译，且允许自由的通过编译参数来做到多系统分别编译不同的代码，因此很多项目都实用这种方式来屏蔽跨系统的 API 差异。但是如果我们在非目标系统进行开发，如在 Windows 或 macOS 开发 Linux 程序，就会出现代码跳转的时候无法跳转到正确的文件。
这是因为 GoLand 默认使用我们开发环境的信息来搜索和跳转，因此如果在 Windows 开发，就会跳转到对应的 Windows 的实现。这时候，我们可以通过修改配置，来修改这一跳转行为。具体需要修改的配置为：
Preferences -> Go -> Build Tags & Vendoring
或者使用双击 Shift 输入 Build Tags 来快速定位到这个配置。
在这个配置里，将 OS 和 Arch （更多…）
通常来说，使用 gdb 等工具调试测试或生产环境的进程，是非常好的查找 Bug 的方式。但是当我们步入容器时代后，使用 gdb 工具却会遇到一些麻烦。
当我们进入容器内，尝试使用 gdb attach 的方式开始调试已运行的进程时，会得到这样的报错：
Attaching to process 123
ptrace: Operation not permitted.
通过简单的搜索我们可以发现，这是因为容器内为了安全，默认没有给 SYS_PTRACE 权限的原因。于是，很多教程告诉我们，用这个命令启动容器解决这个问题：
docker run xxx --cap-add=SYS_PTRACE然而，在生产环境授予容器 SYS_PTRACE 权限是很危险的，有可能造成容器逃逸。因此，如果需要启用该权限，建议慎重考虑。
那么，有没有办法避开这个权限呢？由于容器本身其实就是主机上的一个进程，所以我们自然会想到，能否直接从主机找到对应的进程，然后在主机上执行 （更多…）
今天在解答同事对于 Unix Timestamp 的时区问题的疑问时，看到了这篇文章：
深入理解System.currentTimeMillis()
https://coderdeepwater.cn/2020/12/29/java_source_code/currentTimeMillis/
通过阅读发现，虽然该文章对于这个函数调用的原理解释的非常好，但是却在开头处犯了一个致命的错误，误导了我的同事。在这篇文章中，作者说：
深入理解System.currentTimeMillis()
System.currentTimeMills()的返回值取决于Java运行时系统的本地时区!千万不要忘记这一点!
同一时刻,在英国和中国的两个人同时用System.currentTimeMills()获取当前系统时间,其返回值不是一样的,除非手动将操作系统的时区设置成同一个时区(英国使用UTC+0,而中国使用UTC+8,中国比英国快8个小时).
这个观点是完全错误的，正因为这里的错误误导了我的同事，走入了错误的排查方向。
首先说结论：
System.currentTimeMillis() （更多…）去年末腾讯云轻量服务器推出了内网互联功能，但是好像有很多小伙伴不太清楚用法。因此写本文给大家一些使用思路。
本文基于官方文档 https://cloud.tencent.com/document/product/1207/56847 。
Linux 会为每个进程生成一个目录，保存了进程相关的大量信息。具体位置在：
/proc/${pid}一般有如下文件：
total 0
-rw-r--r-- 1 root root 0 Dec 31 00:00 autogroup
-r-------- 1 root root 0 Dec 31 00:00 auxv
-r--r--r-- 1 root root 0 Dec 31 00:00 cgroup
--w------- 1 root root 0 Dec 31 00:00 clear_refs
-r--r--r-- 1 root root 0 Dec 31 00:00 cmdline
-rw-r--r-- 1 root root 0 Dec 31 00:00 comm
-rw-r--r-- 1 root root 0 Dec 31 00:00 coredump_filter
-r--r--r-- （更多…）最近，线上运行的定时任务出现调度失败。调整了相关参数后，虽然遏制了调度失败的情况，却导致任务调度的延迟极度增加。同时还观察到，在多机部署的环境中，负载极不均匀，于是深入代码排查一番。
org.springframework.scheduling.quartz.SchedulerFactoryBean#setTaskExecutor 方法自定义工作线程池org.quartz.threadPool.classSimpleThreadPool 配合参数 org.quartz.threadPool.threadCount 调整最大线程数即可org.quartz.spi.ThreadPool 接口，并一定要实现 （更多…）AWS 推出的 Lightsail Database 是目前比较实惠的托管 DB 方案。不过相对来说，Lightsail 的控制面板功能较少，很多参数无法修改。经过搜索发现，其实我们有很多参数可以调，只是需要通过命令行的方式来调整。
https://aws.amazon.com/cli/
https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-and-configure-aws-cli
Linux：
sudo apt-get install awscli
MacOS：
brew install awscli
Python（通用）：
pip install awscli
https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-access-keys-to-use-sdk-api-cli
先在 （更多…）
首先，大家都懂，gcr.io 是连不上的，需要使用阿里云镜像或别的镜像
helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.13.0 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/chart --service-account tiller
如果没注意已经部署了，可以先删除：
kubectl delete deployment tiller-deploy --namespace=kube-system
然后，helm install 可能会报没有权限：
Error: release xxx failed: namespaces "default" is forbidden: User （更多…）
众所周知，IPv6 地址中可以用 :: 来省略一连串的 0，于是，在某些情况下，如果 0 被过度合并了，就会导致地址解析的问题。
最近在 AWS 上启用 IPv6 的时候就遇到了这个情况，AWS 分配给我的地址段是：
2406:da14:5c9::/56
可以看出，AWS 实际给我分配的地址是：
2406:da14:5c9:0000::/56
但是由于连续 0 的省略策略，导致 5c9 之后的真正可以被划分的部分被省略了。于是在 AWS 的系统中，子网划分页面就显示成了这样：
2406:da14:5__::/64
按照正常逻辑应该是这样：
2406:da14:5c9:00__:/56
结果当然就悲剧了。这里我除了填 c9 之外，任何的值都会导致划分出的子网不在上面的地址段内，导致划分失败。
所幸的是 AWS 的系统可以随意的解绑地址段，然后重新分配。于是重新分配之后就好了。
不过这里也是对我们的一个提醒：由于 （更多…）
今天在代码中调用 HttpServletRequest 对象的 getCookies() 方法时，发现实际得到的 Cookie 数量与提交的不符。实际提交了 17 个 Cookie，但是获取到的只有 14 个。
经过排查，发现如果调用 getHeaders(“Cookie”) 方法，获取原始的 Cookie 串，是可以拿到正确的 17 个 Cookie 组成的字符串的。于是确认应该是 Tomcat 在处理 Cookie 的时候进行了过滤。
经过一番搜索，发现了这个文档：
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html
其中，跟 Cookie 相关的参数有：
org.apache.tomcat.util.http. ServerCookie.ALLOW_EQUALS_IN_VALUE |
If （更多…） |