Codecooker’s blog

隔离体验卡

2022-04-23T00:00:00+08:00

一直以来总觉得疫情隔离和自己很远，去年多次居家隔离也是走走形式，但是最近一次的体验确实工作后很多年第一次经历。从最初的略有期待（想看看到底是什么情况），到中途的焦躁不安，再到最后的重获自由，整个过程跟做梦一样。简单的把体验分享一下。

起源

4月12号由于工作需要出差到成都，其实成都的防疫情况在我心里一直认为做的比较好，我也始终坚信成都是一个拥有科学防疫办法的城市，所以本次出差并没有考虑太多疫情相关的因素。出发来成都前专门在家做了一次核酸，按照成都的防疫政策，到成都后还需要在本地再做一次，为了不变黄码，13号中午放弃了午睡的时间去郫都区人民医院又做了1次核酸。按说已经做了2次核酸，期间一直在研究所办公，周五晚上还和同事去聚餐，已经完完全全的融入了成都人群。
然而，昨天（4月17日）凌晨，安朴通知10号后来成都的人要居家隔离，看完没当回事，居家隔离嘛，咱有经验。但是后边的消息给我了一个大大的问号，安朴表示自身并没有隔离条件，社区会安排我们隔离。此时的我还以为就是换个酒店而已。整个过程很魔幻，大家还是很配合社区工作。
4月17日下午2点多，大家收拾好行李，我们一行人集中上了一辆不知道去哪里的大巴，在车上听到同行人问另一个“有没有带床单、被罩”，我承认，我当时有些慌了，这绝不是换个酒店那么简单。事实也没有让我失望，我被拉到了这个地方一个一墙之隔的地方。整个过程到现在想起来都很魔幻，但是我们还是大家还是很配合社区工作。

梦开始的地方

到达

当天下午2点48，我们一行人来到了隔离点，有点像电影里接头的场景，一切遵从指令，不能从正常门进入，被大白带着从车库进入。
进入车库后，整个车库就一个大白在等着我们，车库入口大门随即关闭，有种紧张的感觉。

已经关闭的大门

然后就是标准动作，大白叫名字，发防护用品（酒精，一个3m口罩，健康告知书，门牌纸），集中消毒后上楼，消毒完成我们10个人挤在一部电梯了上了楼。我的房间是1xx4，里边设施十分简陋，好在需要的日用品还是都有准备（洗漱用品、热水壶、盆，应有尽有）。这几天恰逢成都降温，整个房间应该是由于长时间没人住的原因，非常的冷。进到房间后落差特别大，恨不得马上离开，简单的铺了下床，就算是可以“安家”了，袋子里有床单，被罩，看着像是新的（走的时候才知道应该是用完洗过的）。

大白集中给箱子消毒

放在门口桌子上的日用品

这个床看起来还是有些伤感

由于房间很冷，就打算睡一会，也是由于冷就没睡着，主要是床给人的压迫感太强了，也不敢脱衣服睡。这里要划线说一点，房子不大，但是有两台挂式空调，可谓豪华配置，但是没有找到空调遥控。好在我是华为手机，有遥控功能，索性双开，这里为自己的机智点赞。

被我打开的空调

送餐很及时，5点半左右，送来晚餐，两荤两素，可谓营养均衡，味道不好（主要还是因为环境，总觉得不干净），量一般，就当减肥了。庆幸自己中午定了一张披萨。

豪华晚餐

由于是周末，下来就是漫长的无聊时间，一点消息都没有，甚至有些绝望，没有人知道外边是啥情况，要隔离到多久，没有一点消息。给街道社区打电话，意料之中的没人接，继续等吧。好消息是晚上房间慢慢的暖和起来，想到对门也是我司员工，于是在门口看了他的电话号码，加了个微信，聊了会儿，拉了群互通有无。

我们的微信群

可能是由于环境不好，晚上一直睡不着，迷迷糊糊的，等差不多了，已经到早晨了，8点半左右，开始发早餐，早餐也是很讲究搭配，但是没胃口。

丰盛的早餐

简单的洗漱了下开始了“居家”办公，工作起来好多了，不知不觉到了中午，想着每次送的饭都不是很好吃就定了个外卖。和生活负责人（对，你没看错，我们有生活负责人）确定了要求，这里要强调下，外卖是不能直接送过来的，而且有很多要求，例如液体不让送（我定了咖啡，最后送外卖小哥了，还和小哥加了微信，小哥表示以后需要直接发微信），不能点熟食，只能是面包一类的。

还是外卖好

就是这个，没法进来

刚收完外卖，午餐就送到到了，午餐依旧是营养均衡，没啥胃口，吃了两口面包，最重要的是午餐有一个粉条炒什么肠的，真是没法吃

午餐

一下午低头看着电脑，脖子非常酸，送饭倒是及时，5点10分左右就送到了，这次还有个鸡腿，这里的生活太规律了，规律的让人有些不适应，每餐都要浪费很多。

晚餐

6点左右启动吃晚饭，生活倒是健康规律，吃完睡了一会儿，睡的脑子疼，期待明天赶紧放出去，回归正常生活。当天晚上可能是由于适应了，也可能是由于暖和了，还睡的不错，早上如期收到了解除隔离通知书，还是有些开心，这个地方是再也不想去第二次了。

解除隔离通知书

然后就是要核酸，鼻拭子，双采，一个鼻孔一下。这里有个小插曲，就是体温的时候，几次都是红的，蛮吓人的，还是护士见多识广，说是空调引起的。出门在手上意思了下，绿了。下来就是漫长的等待，等待被放出去的信号，结果一直等不到，索性跟社区联系，打了无数个电话，都没有接通，这里必须吐槽一下。

这个是解除隔离须知

下午4点左右，跟群里的兄弟约了下直接走，果真就走了，出电梯的时候碰到了工作人员，查验了接解除离通知书，顺利放行，最后在拍了几张照片记录下

看图

终章

出门打个车回到酒店，以最快的速度内外洗了一边，算是回归了正常生活。
这次隔离整体流程还是很正规的，社区服务人员也很礼貌，而且整个过程都是免费的。唯一的遗憾就是自己可能不太适应，整个两天感觉被偷走了一样。
最后，大家一定要做好防护，非必要，不流动！

Github 开发环境

2022-02-14T00:00:00+08:00

github提供在线编辑器，只需要将com改成dev即可。

Java ClassLoader

2021-07-18T00:00:00+08:00

众所周知Java中的类是由ClassLoader负责加载的，最近定位了一个关于类加载的问题，顺便回顾了下Java中类的加载机制，对Java中提供的ClassLoader进行一一说明。

Java中提供的ClassLoader

开始说明该问题前不妨先看看如下代码:

public static void main(String[] args) {
    // 用户自定义类
    // sun.misc.Launcher$AppClassLoader@14dad5dc
    System.out.println(Application.class.getClassLoader());

    // 系统基本类
    // null
    System.out.println(String.class.getClassLoader());

    // ext目录下的类
    // sun.misc.Launcher$ExtClassLoader@1c20c684
    System.out.println(DNSNameService.class.getClassLoader());
}

由上述代码可以看出，用户自定义的类是有AppClassLoader加载，ext目录的类是有ExtClassLoader加载，系统基本类的加载器为null。查看Java手册得知，Java语言自带有3个加载器，分别为:

Bootstrap ClassLoader,最顶层的加载类，主要加载核心类库，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以通过启动jvm时指定-Xbootclasspath和路径来改变Bootstrap ClassLoader的加载目录。比如java -Xbootclasspath/a:path被指定的文件追加到默认的bootstrap路径中。
Extention ClassLoader, 扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。还可以加载-D java.ext.dirs选项指定的目录。
Appclass Loader也称为SystemAppClass, 加载当前应用的classpath的所有类。

双亲委托

简单模型

要弄明白各个ClassLoader是如何工作的，在这里要引入一个新的概念双亲委托,介绍双亲委托之前，我们先看ExtClassLoader、AppClassLoader的源码。从源码中，可以看出一个前提，每个ClassLoader内都包含一个Parent ClassLoader引用，可用通过ClassLoader中的getParent()获取。(用法后边在展开)
AppClassLoader在加载类时会调用如下方法:

 public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException {
    int var3 = var1.lastIndexOf(46);
    if (var3 != -1) {
        SecurityManager var4 = System.getSecurityManager();
        if (var4 != null) {
            var4.checkPackageAccess(var1.substring(0, var3));
        }
    }
    if (this.ucp.knownToNotExist(var1)) {
        Class var5 = this.findLoadedClass(var1);
        if (var5 != null) {
            if (var2) {
                this.resolveClass(var5);
            }
            return var5;
        } else {
            throw new ClassNotFoundException(var1);
        }
    } else {
        return super.loadClass(var1, var2);
    }
}

从源码中可以看出，首先AppClassLoader会判断class是否已经加载，如果已经加载过则从加载过的cache中直接返回，如果不存在则调用super.loadClass进行加载(需要注意的是，这里的super.loadClass只是调动父类方法，而不是Parent去加载)。
跟着代码查看super.loadClass方法：

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }
            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                long t1 = System.nanoTime();
                c = findClass(name);
                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

可以很清楚的看到，super.loadClass同样在cache中查找class是否已经加载，如果加载了直接返回，如果没有加载的话，则调用Parent的loadclass方法加载，当Parent的loadclass为null时，再调用自身的findClass进行查找class，这样就形成了一个双向查找链，大致如下:

首先在cache中找，cache中找不到也不自己加载，而是委托Parent加载
Parent加载不到再委托子加载器按照反方向逐级加载

如上，就是双亲委托的简单模型。

谁是谁的Parent

同样，先看如下代码,Java虚拟机启动时的流程:

public Launcher() {
    Launcher.ExtClassLoader var1;
    try {
        var1 = Launcher.ExtClassLoader.getExtClassLoader();
    } catch (IOException var10) {
        throw new InternalError("Could not create extension class loader", var10);
    }

    try {
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }
    ...
}

在Java虚拟机启动的时分别加载了ExtClassLoader,AppClassLoader。
分别打印各个loader的Parent，如下:

public static void main(String[] args) {
    // 用户自定义类,sun.misc.Launcher$AppClassLoader@14dad5dc
    System.out.println(Application.class.getClassLoader());
    // AppClassLoader->Parent,sun.misc.Launcher$ExtClassLoader@681a9515
    System.out.println(Application.class.getClassLoader().getParent());
    // ExtClassLoader->Parent,null
    System.out.println(Application.class.getClassLoader().getParent().getParent());
}

由结果可以看出，ExtClassLoader的Parent为null，并不代表ExtClassLoader没有Parent，而是因为他是Bootstrap ClassLoader,由于Bootstrap ClassLoader是启动加载器，属于Jvm的一部分，有C/C++编写，在Jvm中处理，所以Java中自然就为null，细心的同学可以在Launcher.class中发现线索，在Launcher.class中有如下配置：

private static String bootClassPath = System.getProperty("sun.boot.class.path");

Bootstrap加载器在启动时通过sun.boot.class.path,来加载启动路径下的class.

为什么双亲委托

谈这个问题，不妨回过头来看看Java的class加载顺序有什么限制，系统类、扩展类都是有Bootstrap ClassLoader，ExtClassLoader加载，无论是否自定义自己的ClassLoader都无法实现覆写诸如String这些基本类的操作，即保留了灵活性，也保证了JVM的运行安全。

自定义ClassLoader

自定义ClassLoader可以有效的保证类隔离，避免互相冲突加载，影响业务功能，同时可以根据业务自身需求提供多种加载方式，例如从网络上加载对应的class，或者在加载class做一些预处理。
定义自己的ClassLoader，同时需要指定Parent，完成双亲代理的双向链条，通常情况下我们可以指定为AppClassLoader,如果不指定则默认为AppClassLoader，如下。

@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
    String fileName = getFileName(name);
    File file = new File(fileName);
    try {
        FileInputStream is = new FileInputStream(file);
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        int len = 0;
        try {
            while ((len = is.read()) != -1) {
                bos.write(len);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        byte[] data = bos.toByteArray();
        is.close();
        bos.close();
        return defineClass(name,data,0,data.length);
    } catch (IOException e) {
        e.printStackTrace();
    }
    return super.findClass(name);
}
// 获取要加载 的class文件名
private String getFileName(String name) {
    int index = name.lastIndexOf('.');
    if(index == -1){
        return name+".class";
    }else{
        return name.substring(index+1)+".class";
    }
}

其中最重要的一点就是调用defineClass方法，完成二进制文件到class的定义。
至此，关于Java的ClassLoader总结到一段落。

人生三重境界

2020-11-22T00:00:00+08:00

最近在搞一个务虚的事情，从痛点分析到目标制定再到措施落地，目标要可量化，措施要可执行，结果要可衡量。
如何衡量一个人的能力，通常会转换成另一个一般化指标，例如，考试分数可以比较客观的反应学生能力，但不能完全代表学生的能力。
所以我们可以将我们的衡量标准价值导向绑定，假设我们绩效导向为代码量，那这个我们定义的能力强就需要包含开发代码量多。

立

昨夜西风凋碧树，独上高楼，望尽天涯路

该阶段需要“立”志，确定目标，也就是价值导向。

守

衣带渐宽终不悔，为伊消得人憔悴

主要为了目标不断的求索，努力。

得

众里寻他千百度，蓦然回首，那人却在灯火阑珊处

付出努力，一步一个脚印，结果（真理）会来找我们，这是一个自然而然的过程。

实操

例如公司需要员工加班，所以我们制定的精英标准需要支撑到公司的诉求。
那我们的目标就是，成为一个加班多的人；可以分解为如下三步：

立：加班工时超过100h
守：拉通、扯皮、放慢节奏、工作留在加班时候干
得：2020年底实现月加班工时100h

Mac用户构建Linux开发环境

2017-12-10T00:00:00+08:00

最近可能会从Mac暂时迁移至Linux环境进行常规软件开发，所以本周末利用空隙时间从Linux发行版本到常用软件再到开发环境的准备做了一个大致的梳理。由于我是重度Mac使用者，所以我会分大概3篇文章来说明怎么准备一个Linux系统便于Mac重度开发者迁移。

发行版的选择

在发行版的选择上，本人也有过纠结，毕竟Linux发行版众多，选出一种合适的发行版确实是一个头疼的事儿。经过慎重考虑，我从Centos、Fedora、ArchLinux、Ubuntu、LinuxMint中选择了LinuxMint。具体原因如下：

LinuxMint是基于Ubuntu的发行版，在Ubuntu的基础了做了一些改变。Ubuntu的优点就是软件支持性好，生态好，这样其实LinuxMint也就可以轻松的借力Ubuntu的软件和社区力量
LinuxMint的桌面环境为基于GNOME Shell的Cinnamon及基于GNOME 2的MATE，另有KDE及Xfce的独立版本可供选择。这个对于不喜欢unity的人是个很好的选择
LinuxMint入门很简单，开闭源驱动支持的很好，当然这点跟Ubuntu没啥区别
家里电脑也装的这个系统

Linux Mint是由Linux Mint Team团队于2006年开始发行，是一份基于Debian和Ubuntu的Linux发行版。其目标是提供一种更完整的即刻可用体验，这包括提供浏览器插件、多媒体编解码器、对DVD播放的支持、Java和其他组件，它也增加了一套定制桌面及各种菜单，一些独特的配置工具，以及一份基于web的软件包安装界面。Linux Mint是对用户友好而功能强大的操作系统。它诞生的目的是为家庭用户和企业提供一个免费的，易用的，舒适而优雅的桌面操作系统。

版本选择

这个不用太纠结，直接选择最新的就行。现在家里用的是半年前安装的18.1，昨天做了最新的安装镜像，18.3，如果条件允许的话，用最新的系统应该不会有什么坏处。这点上不像Ubuntu会有LTS版本，让我这些选择恐惧症的人在这个节点不知道是选择16.04还是明年的18.04

制作安装镜像

第一步，下载镜像

首先下载最新的安装镜像，这个可以直接从官网获取。点击这里打开，记得选择比较近的节点进行下载，中科大有个源是支持的，可以在下载的时候进行选择

第二步，制作安装盘

准备一个不小于2G的优盘，不小于4G最好。下载Universal USB Installer，按照提示一步一步的操作就行，如图(网上盗的图，见谅)

安装

制作完成安装镜像后，就可以重启电脑，然后选择由优盘引导启动进行安装了。这个是Live CD制作的，可以在体验的过程中完成安装。如果是初次安装Linux的话，一点要有几点注意事项：

双系统的话切记备份重要数据再开始安装
不要被那么多的挂载点搞晕，一般情况下，一个swap分区+一个/挂载点就可以了。因为之所以那么多挂载点历史原因比较大
如果是SSD+HDD的电脑，可以外加一个home挂载点，可选一个opt挂载点，这两个挂载点分区至HDD，/挂载点分区至SSD。新的MBR可以写在另一块硬盘上
最好备用网线链接网络的方式，因为无线网卡很有可能并不能正确的安装驱动
如果显卡过新，安装完后可能会导致驱动没有，这个问题也不要惊恐，据我发现，一般A卡的开源驱动都是不错的，N卡的话官方有提供驱动，按照型号去下载安装

安装完成

安装过程一般会很快完成，完成后就可以进行体验了。下一篇我会重点说下如果打造一个和MacOS很相近的开发系统，然后会根据不同的工种开分别说下搭建环境的问题。

Java泛型函数

2017-08-21T00:00:00+08:00

背景

PHP的Array以方便灵活著称，再加上丰富的库函数，可以让开发者灵活的应对大部分需求。经常和数据库打交道的同学，肯定熟悉这个方法array_column

array_column() 返回input数组中键值为column_key的列，如果指定了可选参数index_key，那么input数组中的这一列的值将作为返回数组中对应值的键。

做Java后，我们也常碰到需要如此操作的场景，但并没有合适的库函数，于是本着解放劳动力的出发点，打算自己开发一个。但是由于Java是一个强类型语言，我们经常会碰到如此的类型List<T>，如下：

public class UserInfo {
    private String userName = "codecooker";
    private Integer age = 18;
}


public class school {
    private List<UserInfo> students;


    public List<String> getStudentNameList() {
        // 原始的做法，我们需要遍历
        List<String> studentName = new ArrayList<>();
        for (UserInfo usInfo : this.students) {
            studentName.add(usInfo.userName);
        }

        return studentName;
    }
}

泛型方法

解决方案是由于看到系统函数的实现有所启发，想到了泛型函数。下面从自己的理解对泛型函数做一个简单的解释
一般的泛型函数形式如下：
其中
1表示在此泛型函数中我们定义要使用的泛型，这里只代表一个符号，可以试T也可以是
2表示该泛型函数的返回类型，必须是已经定义过的类型，比如是T或者U
3方法名
4、5参数列表
这里需要注意区分泛型方法和不同泛型类内使用泛型的方法的区别，例如:

public class Test<T> {
    // 泛型方法
    public static <T,U> List<T> clounms(List<U> list, Function<U,T> function);

    // 不同类成员方法，只不过是返回了一个类定义时的泛型列表
    public List<T> getALl();
}

其实，按照我的理解，最重要的区别就是是否有在方法定义时有泛型的定义过程，如果有则是泛型方法。

实现array_column方法

有了上面的铺垫，我们可以定义简单的泛型方法来实现array_column的功能

public class ListUtil {

    public static <T,U> List<T> clounms(List<U> list, Function<U,T> function) {
        List<T> result = new ArrayList<>();
        for (U u :
                list) {
            result.add(function.apply(u));
        }

        return result;
    }
}

如此，完成

Linux安装PHP7.x

2017-02-17T00:00:00+08:00

众所周知，PHP7的性能和执行速度都有了很大的改进。恰逢最近公司的一些项目也在尝试着迁移到PHP7的环境，由于本人平时开发使用MAC和Linux，而且不愿意使用现成的批量部署工具（不是愿意重复造轮子，而是想知道到底安装了哪些东西）。所以就选择自己编译安装环境。

获取源代码

PHP源代码是开源的，我们可以在PHP的官方下载我们需要的源码包，这里我们以PHP7.1.1为例

# 下载源码
wget http://cn2.php.net/get/php-7.1.2.tar.gz/from/this/mirror
# 解压
tar xvf mirror

安装依赖库

下面就列举下常用的Centos7.x和Ubuntu系的依赖安装

Centos

# 包含扩展依赖的开发库
sudo yum install libxml2 libxml2-devel openssl openssl-devel bzip2 bzip2-devel libcurl libcurl-devel libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel gmp gmp-devel libmcrypt libmcrypt-devel readline readline-devel libxslt libxslt-devel
# 包含编译源码必要的类库
sudo yum groupinstall "Development Tools"

Ubuntu

sudo apt-get install libcurl4-openssl-dev libbz2-dev libssl-dev libxml2-dev libjpeg-dev libpng12-dev libfreetype6 libfreetype6-dev libgmp3-dev libmcrypt4 libmcrypt-dev libreadline-dev libxslt1.1 libxslt-dev  

开始编译

进入我们的源码目录，首先配置安装。安装上所有常用的扩展。注意，这里的PHP的安装目录是/alidata/server/php

./configure \
--prefix=/alidata/server/php \
--with-config-file-path=/etc \
--enable-fpm \
--with-fpm-user=nginx  \
--with-fpm-group=nginx \
--enable-inline-optimization \
--disable-debug \
--disable-rpath \
--enable-shared  \
--enable-soap \
--with-libxml-dir \
--with-xmlrpc \
--with-openssl \
--with-mcrypt \
--with-mhash \
--with-pcre-regex \
--with-sqlite3 \
--with-zlib \
--enable-bcmath \
--with-iconv \
--with-bz2 \
--enable-calendar \
--with-curl \
--with-cdb \
--enable-dom \
--enable-exif \
--enable-fileinfo \
--enable-filter \
--with-pcre-dir \
--enable-ftp \
--with-gd \
--with-openssl-dir \
--with-jpeg-dir \
--with-png-dir \
--with-zlib-dir  \
--with-freetype-dir \
--enable-gd-native-ttf \
--enable-gd-jis-conv \
--with-gettext \
--with-gmp \
--with-mhash \
--enable-json \
--enable-mbstring \
--enable-mbregex \
--enable-mbregex-backtrack \
--with-libmbfl \
--with-onig \
--enable-pdo \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-zlib-dir \
--with-pdo-sqlite \
--with-readline \
--enable-session \
--enable-shmop \
--enable-simplexml \
--enable-sockets  \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--with-libxml-dir \
--with-xsl \
--enable-zip \
--enable-mysqlnd-compression-support \
--with-pear \
--enable-opcache \
--with-libdir=lib64

配置和检查完依赖后，下来就要开始编译了

make

# 如果一切顺利，make结束后，安装就行。如果安装目录没有当前用户的写权限，需要上sudo
sudo make install

安装完成

安装完成后，还需要做两小步骤

添加/alidata/server/php/lib/php到php.ini的include_path
添加/alidata/server/php/bin 到环境变量，方便后续使用

至此，PHP安装完成

➜  /etc php -v
PHP 7.1.2 (cli) (built: Feb 17 2017 23:04:39) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologie

常见错误处理

Centos7 安装报如下错误

libmcrypt libmcrypt-devel未找到，需要下载源码进行安装。默认安装在 /usr/local/lib
编辑文件/etc/ld.so.conf，添加/usr/local/lib到最后，执行ldconfig

ThinkPHP定时任务（一）

2017-01-23T00:00:00+08:00

后台开发的过程中，免不了和定时任务打交道。每天定时的发短信给用户，定时的计算收益、利息，固定间隔的去执行某项大型任务（不适宜同步执行）等等，等等
常用的定时任务都是基于linux中的crontab进行，不过今天我们主要做TP框架内的定时任务实现解析，分析其实现原理和缺陷。在下一部分，会介绍一个新的方案

行为扩展

细心的朋友应该知道TP框架中有一个名叫行为扩展的东西。其实简单的概括起来就是HOOK,可以实现在某个时机进行HOOK，然后注册监听(Listen),实现代码和功能的无侵入式嵌入。行为扩展在我们的项目中使用的比较多，静态资源替换、错误模板替换（这个只有经历过才知道为什么）、自动初始化，太多的地方。总体来说，由于TP暴露了很多关键点的HOOK，我们在使用的时候，只需要去监听即可，所以使用起来还是很不错的。如果对行为扩展还有不了解的，可以去查看TP官方文档寻找答案

基于行为扩展的定时任务

没错，TP的定时任务既是建立在自身的行为扩展的基础上的，如果了解了行为扩展的朋友，应该知道行为扩展只是一种变相的代码调用，所以问题就随之而来，什么时候触发定时任务？我们先来看看在框架内应该以什么样的姿势来打开Crons
一般情况下，我们做如下初始化：

// Common/Conf/tags.php 文件
'app_begin'=>array(
    'Behavior\CronRunBehavior'
),

Common/Conf/tags.php 文件用于快速的注册行为扩展，跟HOOK有异曲同工之处。由于这个方法比较简洁方便，且对于框架代码无嵌入，值得使用

这个注册的意思是在程序启动的时候，直接调用Behavior\CronRunBehavior脚本，而Behavior\CronRunBehavior脚本的任务既是对定时任务的调用

时间间隔

做定时任务，肯定要关心调用频次，这里我们看下CronRunBehaviorController的实现代码来简单的分析下这个定时任务的实现逻辑
如下代码:

 // 锁定自动执行
 $lockfile    =   RUNTIME_PATH.'cron.lock';
 if(is_writable($lockfile) && filemtime($lockfile) > $_SERVER['REQUEST_TIME'] - C('CRON_MAX_TIME',null,60)) {
        return ;
 } else {
            touch($lockfile);
 }
 set_time_limit(1000);
 // 即使客户端断开连接，也要继续执行
 ignore_user_abort(true);

这段代码的意思是，在执行CronRunBehaviorController前，大概分为如下流程:

判断是否有锁文件，如果没有则创建锁文件，进行下一步，如有进行第2步
判断所文件的创建时间是否和当前时间间隔超过我们设置的时间间隔CRON_MAX_TIME，默认为60s，如果超过则进行下一步，反之不执行，直接退出

再看下面代码：

if(is_file(RUNTIME_PATH.'~crons.php')) {
    $crons  =   include RUNTIME_PATH.'~crons.php';
}elseif(is_file(COMMON_PATH.'Conf/crons.php')){
    $crons  =   include COMMON_PATH.'Conf/crons.php';
}

这块代码可以看出来我们的定时任务配置是在Conf/crons.php路径下，有runtime缓存，每次修改需要清除缓存，这里比较简单，我来贴上Conf/crons.php的配置即可

 return [
    'callback' => array('Agreement/Cron/call_back.php', 0.1),
 ];

其中callback是任务脚本名称，而对于的value则是任务脚本的配置
'Agreement/Cron/call_back.php'为具体执行脚本，依次为间隔时间，上次执行时间

至此，我们的基于TP的定时任务已经全部准备就绪。

写在最后

优势

方便使用，如果是用TP实现的代码逻辑，全部逻辑都可以复用
不用考虑实现具体调用细节，只需要按照规范来写就行
所有的参数都比较直白，不用和crontab中的星星打交道
对时效性不强的简单定时任务可以首选

缺点

由实现逻辑可以看出，每次脚本的启动都是由客户触发，不能保证稳定的时间间隔
配置时间不是很灵活（之前为了使用，也做了些许扩展）
同步执行，很影响使用这的执行效率，如果任务脚本比较大，则会极度影响用户体验
文件锁的方式虽然好用，但是对于分布式系统，无法做到锁功能

尝试过的改造

对配置文件进行了升级，支持间隔时间的配置
对执行方式进行了改造，支持基于pcntl的多进程调用，由于主进程需要先结束，为了实现逻辑最后造成进程混乱，不是很可取。
使用redis对执行加锁，完成分布式锁

上述改造，由于第三点不好处理（也是最重要的一点），遂另辟蹊径，采用了另一种方式来处理。下一章节，我会对这个进行详细说明！

ThinkPHP定时任务（二）

2017-01-23T00:00:00+08:00

前面说了TP框架中定时任务实现，也对存在的问题和优势做了一个简单的分析。如果有兴趣看的朋友可以参看ThinkPHP定时任务（一）。这篇主要对基于传统定时任务crontab[守护进程]，外加TP框架支持实现的基于TP的定时任务

动机

用过TP的朋友都知道，TP框架是一个由国人开发的很优秀且轻量的PHP Web框架。由于其丰富的文档和强大的用户群体，在国内有不错的保有量。记得之前项目之初选择框架的时候，朋友建议选择TP，给的建议就是用户群体大，便于招人。
TP在Web模式下获得除了不俗的成绩，但是在非CGI模式下，通常（CLI），缺罕有人用。究其原因，个人觉得，无外乎以下几点：

文档解释的比较少
对CLI模式本身支持的比较简单
有这样前后台执行需求的用户大多选择了laravel等国际框架

然而，我们的工程确实是用TP开发，为了保证代码结构统一，不用重复造轮子。就难免需要探索下TP框架下怎么实现后台任务的执行，如果这个问题解决了，再结合crontab就能找到我们想要的解决方案

TP框架的Mode

mode即是指应用模式，TP文档中是这么说明的：

应用模式提供了对核心框架进行改造的机会，可以让你的应用适应更多的环境和不同的要求。每个应用模式有自己的模式定义文件，用于配置当前模式需要加载的核心文件和配置文件，以及别名定义、行为扩展定义等等。根据模式定义文件的定义位置和入口是否需要定义模式，可以分为显式应用模式和隐含应用模式。

而这里，我们要使用的就是TP3.2自带的api模式，要开启api模式，我们只需要做如下简单的配置

//cli模式
define('APP_MODE','api');

这个宏有默认值，如果我们没有定义的的话，会在应用的入口自动设置为我们的常用模式

defined('APP_MODE')     or define('APP_MODE',       'common'); // 应用模式 默认为普通模式   

关于api模式的配置文件，可以参考Think/mode/api.php，里边有对内置api应用模式的基础配置，我们可以根据我们的需求进行改写，或者通过配置覆写系统配置。而我们常用的普通模式就是该目录下的common.php，大家可以对比进行学习

兼容配置

APP_PATH 配置

由于我们的应用是在普通模式下工作的，当我们在调用API模式时，肯定希望应用目录保持一致，这样就不用做任何代码的迁移和改动。在api模式中加入如下配置

// 定义应用目录,同样指向common模式下的app目录
define('APP_PATH','../Apps/');

APP_STATUS 配置

起先，本人以为截止上一步就完成了所有配置。但是在调试的过程中，发现数据库无法连接，最终定位到。APPS目录中的配置没有正常加载。这个过程是个比较长的调试过程，具体就不表了。查看源代码发现，common模式下的所有配置是在Think/Libary/Think/Dispatcher.class.php中进行引入的，其中有如下代码，是完成MODULE中配置的加载的，有兴趣的同学可以自己看看

// 当前应用状态对应的配置文件
if(APP_STATUS && is_file(MODULE_PATH.'Conf/'.APP_STATUS.CONF_EXT))
    C(load_config(MODULE_PATH.'Conf/'.APP_STATUS.CONF_EXT));

    // 加载模块别名定义
    if(is_file(MODULE_PATH.'Conf/alias.php'))
        Think::addMap(include MODULE_PATH.'Conf/alias.php');
    // 加载模块tags文件定义
    if(is_file(MODULE_PATH.'Conf/tags.php'))
        Hook::import(include MODULE_PATH.'Conf/tags.php');
    // 加载模块函数文件
    if(is_file(MODULE_PATH.'Common/function.php'))
        include MODULE_PATH.'Common/function.php';
    // 加载模块的扩展配置文件
    load_ext_file(MODULE_PATH);

同样找到Think/Mode/Api/Dispatcher.class.php,在合适的时机添加上述加载代码(本人TP3.2是在146行开始加的)，这样后就可加载MODULE中配置。
至此，所有的配置均已完成，下来我们来看看怎么操作。

目录结构

先看看我这边的目录结构吧，便于后续表述

    PROJECT
        - APPS
            + module_1
            + module_2
        - Crons
            + crons.conf
            + curl_runloop.sh
            + daemon.sh
            + exec.php
            + runloop.sh
            + start.sh

Crons就是我们的定时任务目录，这里我着重说一下Crons目录下各个文件的用途吧。

crons.conf 定时任务的配置文件，配置了要执行什么定时任务
curl_runloop.sh 通过url调用时的runloop脚本
daemon.sh 守护进程
runloop.sh 直接PHP调用的runloop脚本
exec.php命令执行脚本

如何执行

有了上面的铺垫，启动脚本其实很简单，如下：

php exec.php script_path

这里做个简单的说明，比如我们之前的访问的URL如下：

http://xxx.com/abc/controller/action

我们的script_path的值应该传:

abc/controller/action

这样即可调用的我们的对应方法，完成后台执行

时间控制

定时任务肯定逃不过计划执行时间，轮训时间。这里我从controller层做了些许限制。当然也可以在runloop中去做。将配置信息写在crons.conf中。进行配置既可
建立一个用于执行定时任务的基类来统一处理调度和并发逻辑。需要能别后台调用起的定时任务需要继承该基类，完成基础功能。主要涉及的一下几个地方。

// cronbaseclass 实现

// 多少时间执行一次
protected $interval = 60;

// 检测是否有权限调用
private function check() {
    if (PHP_SAPI != 'cli' && !in_array(get_client_ip(),C('CRONS_BIND_IP'))) {
        exit('what a fucking day!');
    }
}

// 入口方法
public function index() {
    set_time_limit(0);
    $exe_time = $this->cron_config(CONTROLLER_NAME.ACTION_NAME);
    if ($exe_time < time()) {
        $this->update_cron_config(CONTROLLER_NAME.ACTION_NAME,$this->interval + time());
        $lock_file = RUNTIME_PATH.md5(CONTROLLER_NAME.ACTION_NAME);
        if (empty(S($lock_file))) {
            S($lock_file,1,600);
            $this->run();
            S($lock_file,null);
        }
    }
}

// 子类逻辑执行方法
protected function run() {}

runloop

runloop 其实很简单，就是一个死循环，然后去读取配置文件，通过php exec.php xxx去执行脚本任务。特别需要注意的daemon.sh脚本，是我们统一守护进程。crontab中需要进行配置如下：

# 守护进程守护runloop.sh进程，去执行release环境[APP_STATUS]
* * * * * daemon.sh runloop.sh release

结语

到现在，我们所有的配置和执行方案已经分析完成。根据这些配置，大家可以灵活的组织各种定时情况。
其实每个框架都有自身的强大之处和不足，只要根据它的特性和设计方案出发，一般都能找到合适的方案。自己碰到的问题，相信框架的设计者也有所涉及。本文其实就是在TP的框架中做了一些小的改动来支持定时任务。

附录

crons.conf内容格式

Agreement/CCallback
Agreement/Achive
Agreement/SynchronizeStatus

2016年终总结

2016-12-31T00:00:00+08:00

不忘初心，以己为镜，继续努力！