下面是之前2-3个月积攒的文摘，清空一下，所以有些看起来可能是不够“新鲜”了。

1, Dubbo源代码分析九：优雅停机
http://manzhizhen.iteye.com/blog/2404220
这几天从dubbo-admin有机会看了一点dubbo代码，对上述shutdown方式，有了点体会。
可以说2.5.3版本 dubbo和dubbo-admin交互还是有多处bug的，比如可以对比 com.alibaba.dubbo.registry.integration.RegistryProtocol在2.5.3和2.5.8版本的实现（doChangeLocalExport/notify方法）。

3，python根据项目生成requirements.txt
查看一些python项目，很多并未采用requirements.txt方式，编译起来耗费时间，今天学到了可以用 pip freeze的方式：

python项目中必须包含一个 requirements.txt 文件，用于记录所有依赖包及其精确的版本号。以便新环境部署。
在虚拟环境中使用pip生成：
(venv) $ pip freeze >requirements.txt
这种方式配合virtualenv 才好使，否则把整个环境中的包都列出来了。
使用 pipreqs
这个工具的好处是可以通过对项目目录的扫描，自动发现使用了那些类库，自动生成依赖清单。
缺点是可能会有些偏差，需要检查并自己调整下。
# pip install pipreqs
# 使用方式也比较简单
pipreqs ./

很久没有写博客了，感觉快要生疏，今天简单写一点，记录发现的几个问题。

1，
在集群增加一个节点后，不要只看是否启动成功，一定要验证下是否加入集群
考虑到32G内存的官方推荐，很多人会选择同一物理机部署两个以上节点（>128G内存），分配两个端口。比如9300/19300.
比如集群在 10.135.30.12:9200/9300 是一个master节点，之后拷贝配置新增如下一个节点：

1
2
3
4
5

cluster.name: elasts
node.master: false
node.data: true
transport.tcp.port: 19300
discovery.zen.ping.unicast.hosts: ["10.135.30.12"]

会发现该节点启动成功，但是没有加入到elasts这个cluster里。 设置为debug级别再启动，不仔细看是发现不了问题的。

很久没有更新了，最近比较忙。
今天刚好是第33个教师节，怀念因吾逃课多次而气哭却依旧对我苦口婆心谆谆教诲到毕业的高二高三班主任。可惜花无重开日，人无再少年。当爱因斯坦霍金这些天才的头脑思考想象时间之箭逆向的时候，凡夫俗子只能哀叹滚滚长江东逝水，但将白发唱黄鸡？
所以，第一个链接附上：邓晓芒的邓晓芒：我的恩师修斋先生

1. 优雅停机
   dubbo原生是支持优雅停机的，其实也就是采用JDK的ShudownHook来实现，当然仅限kill -15 PID。这里也顺带说一下dubbo优雅停机的原理，如下所示：
   服务提供方
   · 停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
   · 然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。
   服务消费方
   · 停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
   · 然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。
   阅读全文 »

1. 阿里周洋分享了中间件技术峰会分享|双11高可用架构演进之路, 介绍了阿里第四代技术架构，将其分为了，容量规划、限流降级、依赖治理、开关预案、故障演练、流量调度。
   其实这是一系列，另外一篇中间件技术峰会分享|阿里电商架构演变之路，很简略的概括了阿里架构史，其实也是国内很多公司开发的架构史。里面将淘宝架构分为：
   淘宝从初创开始到今天，我们的技术架构总体上经历了四代：
   第一代是基于LAMP的一套结构。第二代是基于Java的应用架构。第三代是基于分布式体系，构建出一整套的分布式架构。第四代是基于IDC，不但应用能够分布，整数数据中心也能够分布。
   这里也可以看出，前三代，阿里跟随国外技术圈。本人工作过几家大公司其实也是该思路。

2. 10,000 Java performance tips over 15 years - what did I learn
   上面是油管链接，也可以去voxxed 2017, devoxx conf上面一些基于JVM语言／优化等链接还是很值得看的。

   阅读全文 »

记录一下看书收获。

1. 什么是熵

让我们先看一下维基百科对玻尔兹曼熵的来源描述和定义：

熵（Entropy），是一种测量在动力学方面不能做功的能量总数，熵的量度正是能量退化的指标。
熵亦被用于计算一个系统中的失序现象，也就是计算该系统混乱的程度。
1877年，玻尔兹曼发现单一系统中的熵跟构成热力学性质的微观状态数量相关。玻尔兹曼并假设：
S=k*lnΩ
公式中的k是玻尔兹曼常数，Ω则为该宏观状态中所包含之微观状态数量。这个被称为玻尔兹曼原理的假定是统计力学的基础。
统计力学则以构成部分的统计行为来描述热力学系统.

这就是玻尔兹曼的Entropy的来源了，而当普朗克来中国讲学时用到entropy这个词时，还没有对应名称，胡刚复教授偷懒地根据公式（dS=dQ/T），把“商”字加火旁来意译“entropy”这个字，创造了“熵”字（胡刚复与叶企孙同样是我国近代物理奠基人）。
不过上面是物理学衍生的玻尔兹曼熵，在1948年，克劳德·艾尔伍德·香农将热力学的熵引入到信息论，定义了信息熵的概念，因此它又被称为香农熵。

在信息论中，熵是接收的每条消息中包含的信息的平均量，又被称为信息熵、信源熵、平均自信息量。
这里，“消息”代表来自分布或数据流中的事件、样本或特征。

这即是熵的定义了，这里隐含的想法是，比较不可能发生的事情，当它发生了，意味着更多的信息。
所以熵也可理解为不确定性的量度[Measure of Uncertainty]，即越随机的信源的熵越大。

分享一下在学习逻辑回归时候的困惑，以便需要者节约时间。

在看西瓜书的逻辑回归这一章时，对作者引入了sigmoid函数觉得突兀，于是搜索到了知乎上的提问，为什么 LR 模型要使用 sigmoid 函数 里获赞最高的答案。
但正如马化腾先生说的，这么说，也对也不对。
看完后，上面其他回答各种理由，而匿名回答是最大熵的，并不是原因，甚至，这可以认为是一个推论或公理。试想再问为什么要熵最大化？
换言之，一个分析问题是从前一步的因，一个分析问题是从最初的因。这对数学专业可能会直接跳过这么问。

Blogs

1, 10,000 Hours With Claude Shannon: How A Genius Thinks, Works, and Lives
上个世纪，尤其是前50年，伟大的天才很多，开拓的天才屈指可数，有些是大众皆知如爱因斯坦，图灵，而知道香农就没有那么多。作者总结了香农许多习惯，试图解密为何香农会有那么多的时间创造，或者思考。
2，Makers专访Margaret Hamilton, NASA’s First Software Engineer

Meet Margaret H. Hamilton, the woman who led man to the moon. 
On July 20th, 1969, minutes before Apollo 11's scheduled touch-down, 
there was a computer error that would have changed history had it not been 
for Margaret's programming that overrode the glitch and ultimately made 
"one small step for man, and a giant leap for mankind" a reality.

旧文，现重新整理下：

1. 缘起

最近有同事发来如下一段异常，程序已开始运行正常，只是很快就会莫名其妙的抛这个异常，不知道如何着手解决:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Exception in thread "main" java.lang.NoClassDefFoundError: sun/reflect/ConstructorAccessorImpl
    at sun.misc.Unsafe.defineClass(Native Method)
    at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:394)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:393)
    at sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:92)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:55)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at com.thomas.classloader.unload.MonitorHotSwap.main(MonitorHotSwap.java:34)
Caused by: java.lang.ClassNotFoundException: sun.reflect.ConstructorAccessorImpl
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    ...

我把他的代码稍作简化，主要部分是类似下面的逻辑，功能是程序监控某几个文件的变动，发现符合条件就会编译并会重新加载class，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class HotSwapURLClassLoader extends URLClassLoader {
    @Override
    public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        Class<?> clazz = null;
        clazz = findLoadedClass(name);
        if (clazz != null) {
            //...一段热替换逻辑
        }
        if (name.startsWith("java.")) {
            try {
                ClassLoader system = ClassLoader.getSystemClassLoader();
                clazz = system.loadClass(name);
                if (clazz != null) {
                    if (resolve)
                        resolveClass(clazz);
                    return (clazz);
                }
            } catch (ClassNotFoundException e) {
                // Ignore
            }
        }
        return customLoad(name, this);
    }
    ...
}
class X {
    ...
    public void hot(String msg) {
        //System.out.println(String.format("ver:%s, classLoader: %s.", ver, this.getClass().getClassLoader()));
    }
}

上面的异常，不同于常遇到的异常，我们根据异常栈逆推可能不会很容易的定位到root cause。所以我在hot方法加了一条日志信息，即注释打开，运行多次，发现每次都是

1
2

ver:15, classLoader: com.thomas.unload.HotSwapURLClassLoader@4e25154f.
Exception in thread "main" java.lang.NoClassDefFoundError: sun/reflect/ConstructorAccessorImpl

这让我想起了JVM参数有inflationThreshold=15

这是一篇老文章，记录了发现PySpark一个bug的过程，现重新整理下：

截止2016-05-19已发布最新Spark版本，如果你在使用pySpark，并且也用 import random的方式生成随机数,就可能会遇到下面的问题：

刚学Spark，故先看一段Monte Carlo method 求Pi的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

from random import random
from operator import add
def funcx(x):
  # print x[0],x[1]
  return 1 if x[0]**2 + x[1]**2 < 1 else 0
def genRnd(ind):
  x=random() * 2 - 1
  y=random() * 2 - 1
  return (x,y)
def runsp(total):
  ret=sc.parallelize(xrange(total),1).map(genRnd).map(funcx).reduce(lambda x, y: x + y)/float(total) * 4
  print ret
runsp(3)

spark-shell方式运行上述代码，多次运行runsp(n), 会发现几点有趣现象：

1, 按理说, n越大，虽不是越能逼近pi，但是逼近pi的概率应该是越大的。然而发现似乎并不如此，起初以为是python生成伪随机算法导致，还好通过下面一个现象发现问题。但是伪随机算法在多大程度上干扰了Monte Carlo求值？这个后面会写一篇从数学上分析下。