首先，大家都懂，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 （更多…）
在功能和使计算机保持最新状态这两个方面，Office 2016 for Mac 的默认配置提供了最佳用户体验。
在某些情况下，可能希望阻止应用程序联系网络终结点。
若要防止应用程序发送“使用情况”遥测可从终端手动设置：
defaults write com.microsoft.WordSendAllTelemetryEnabled -bool FALSE defaults write com.microsoft.WordSendAllTelemetryEnabled -bool FALSE defaults write com.microsoft.ExcelSendAllTelemetryEnabled -bool FALSE defaults write com.microsoft.PowerpointSendAllTelemetryEnabled -bool FALSE defaults （更多…）
简单记录一下 ESXi 主机更换 HTTPS 证书的方法：
# castore 用处尚未查证，不建议修改 /etc/vmware/ssl/castore.pem # crt 使用 nginx 格式，将证书和中间证书合并在一个文件里 /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.key services.sh restart
因为不建议开启 SSH 服务，所以不推荐远程更换的方法。
如果需要 Let’s Encrypt 解决方案，建议参考这个脚本：
众所周知，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 的系统可以随意的解绑地址段，然后重新分配。于是重新分配之后就好了。
不过这里也是对我们的一个提醒：由于 （更多…）
首先铺垫一下，这段代码的输出是什么？
public static void main(String []args){
System.out.println(Integer.MAX_VALUE + 1);
}
很多人可能很快就能答出来，正确答案是：-2147483648
那么接下来看这段代码：
public static void main(String []args){
Long total = Long.MAX_VALUE;
for (int i = 0; i < total; i++) {
System.out.println(i);
}
}
乍看之下似乎没啥大毛病，但是结合前面的铺垫，就会发现：
当 i 增长到 Integer.MAX_VALUE 的时候，“奇迹”出现了。接下来，下一个 i 值变为了 -2147483648。跟 （更多…）
在 MyBatis 中，获取自增 ID 主要有两个方法：
针对这几种方法，有几个小问题需要注意：
（本文所有内容基于 Oracle JDK）
由于 DNS 解析是一个访问量大的不是很可靠的网络调用，因此通常大部分系统都会对 DNS 解析的结果进行一定程度的缓存。如运营商的 LDNS、常用的浏览器、包括操作系统本身，都会对 DNS 解析的结果进行缓存。在 JVM 中，为了加速 DNS 解析的过程，当然也进行了相关的缓存。
在 Java 中，最常用的进行 DNS 解析的方法就是：
java.net.InetAddress.getAllByName(“www.google.com”);
而这个方法本身也会对解析的结果进行相应的缓存。看官方文档：
InetAddress Caching
The InetAddress class has a cache to store successful as well as unsuccessful （更多…）
今天在排查一个线上问题是发现一个使用 ScheduledExecutorService 执行的定时任务在执行了一次以后就再也没有执行过了。于是 Dump 了内存来检查问题。
首先，搜索对应 Task 的类，发现在堆中找不到这个类的实例。可是明明已经成功执行了一次，为何没有实例？
于是再去找 ScheduledExecutorService 对应的 ScheduledThreadPoolExecutor 类，成功筛选出了用来执行定时任务的实例。在实例的 queue 中，却只看到了 6 个 Task 对象，唯独不见了这个出问题的对象。百思不得解，因为日志中这个对象的 Logger 已经打印出来了，说明至少执行了一次，为啥会从内存中消失呢？
在同事的帮助下，查阅了 API 文档，发现了这么一句话：
If any execution of the task encounters （更多…）
前几天接到反馈，线上某机器上的服务在进行后端调用的时候失败了。查看日志是端口分配失败。通过 netstat -nulp 看到大量端口占用，用户段端口49152 到 65535 全部被占满。于是通过 awk sort 和 uniq 统计出每个进程的端口占用情况，发现某些 Java 服务占用了 2w+ 端口，于是对该服务展开分析。
首先考虑的是应用有大量 Socket 对象没有关闭释放，于是将堆 dump 出来，使用 VisualVM 加载分析。由于泄露的是 UDP 端口，于是考虑查找 Java 中 UDP socket 对应的对象 DatagramSocket 。可是一顿操作之后发现堆中并不存在该类对象，倒是找到了几个 DatagramSocketAdaptor 对象。查看了框架发现使用了 Netty 做 NIO，因此实际使用的是 NioDatagramChannel 和 DatagramSocketAdaptor （更多…）
今天在代码中调用 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 （更多…） |