前言

维护linux时，怎么kill命令怎么写使用才能方便？

找到pid
ps -aux|grep "程序特征"|grep -v grep|cut -c 9-15

ps -ef|grep "程序特征"|grep -v grep|awk '{print $2}'

示例：
shell> ps -ef|grep 'apache-tomcat-8.5.24-9050'|grep -v grep|awk '{print $2}'
885
shell> ps -aux|grep 'apache-tomcat-8.5.24-9050'|grep -v grep|cut -c 9-15
   885

kill命令模板

当有重复性的需要kill某个程序时，可以通过下面的模板方便的执行kill。
风险：切忌无脑执行。否则会误杀程序。
命令模板

ps -ef|grep "程序特征"|grep -v grep|awk '{print $2}'|xargs kill -9
ps -aux|grep "程序特征"|grep -v grep|cut -c 9-15|xargs kill -9

用法

确定好“程序特征”，套用模板
kill 程序 yumBackend 时可以这样用：

ps -aux|grep yumBackend|grep -v grep|cut -c 9-15|xargs kill -9


kill 某个自己写的程序时可以这样用：

ps -aux|grep xx.jar|grep -v grep|cut -c 9-15|xargs kill -9


程序特征如何识别？通过ps -aus分析程序特征。特征要保证唯一性。

当前目录下 查找含有vectorAdd的文件和目录
find . -name "*vectorAdd*"

当前目录下 查找含有vectorAdd的目录
find . -type -d -name "*vectorAdd*"

文章目录
@[toc]
1.背景前言
2.命令模式
2.1 命令模式概念
2.2 命令模式角色
2.3 命令模式分析
2.4 命令模式的优点
2.5 命令模式的缺点
1.背景前言
传统的OO思维：
设计一个家庭控制软件，可以通过遥控器来控制各个家具。
现有一个空调，那么遥控器接口大致为：
OnOrOffButton方法 ----- 开关接口负责控制开或关，
Control方法 ------ 升降接口负责控制温度升高或降低
Switch方法 ------ 模式接口负责切换空调的模式切换。
代码写好了。
这时候来了一个新需求，家里买了一个智能音响。
那么代码除了需要添加一个针对智能音响的类，还需要对上面三种方法进行修改，添加智能音响的属性以及功能实现。
那么如果家里买了一堆堆的智能家具，那么这个代码就要重复n多遍已完成对所有智能家具的控制。很明显，这样虽然功能是能实现，但是再扩展性和维护性上就不好了。整体的开发效率也相对低很多。
通过仔细观察，可以发现所有的方法其实是通过遥控器来实现调用的（物联网下，一个控制器可以控制多个设备，例如小米家庭那个软件），遥控器是通过命令将指令发送出去，完成功能实现。
这时候，当遇到需要通过命令来处理各个请求的时候，命令模式就登场了！
2.命令模式
2.1 命令模式概念
百度百科：在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）。
2.2 命令模式角色
1、Command：命令 ----- 为所有命令声明了一个接口，或者把命令封装成一个抽象类，每一个命令都是一个对象。调用命令对象的 execute()方法，就可以让接收者进行相关的操作。这个接口也具备一个 undo() 方法。注意标黑，所有命令！
----->>Command也可以定义成类，在Command里面可以把具体的一些接收者声明一下，这样在后面具体命令类中，就可以直接
public abstract class Command {
    //定义具体命令最终的对象类（其实就是下面会提到的接受者），这样Command的子类就可以直接调用了，说白了，就是把能接受命令的对象生命在这里。发布命令的时候就可以直接一步到位了
    protected AirCondition ac = new AirCondition();
    protected Stereo sto = new Stereo();
    
    public abstract void execute(); //执行命令
    public abstract void undo();    //撤销命令
}

2、ConcreteCommand：具体命令 ----- 实现命令接口，定义了动作和接收者之间的绑定关系。调用者只要调用 execute() 就可以发出请求，然后由 ConcreteCommand 调用接收者的一个或多个动作。
----->>这里的ConcreteCommand其实就是具体的命令啦，比如AirConditionOnCommand来控制空调开启和关闭的命令。StereoOnCommand来控制智能音响的开启和关闭命令。客户的任何新需求都可通过增加一个具体的Command子类，实现一个具体命令。每一个命令都将封装起来。在这里才真正的定义了命令与接收者的关系，在高层是看不到命令对应的接收者是谁，也不关心。
public class StereoOnCommand extends Command {
    /**
     * 重写Command命令类的方法
     */
    @Override
    public void execute() {
        //当然，在这里也可以调用其他在command中声明的接收者，进行组合完成执行命令
        super.sto.on();
    }
    @Override
    public void undo() {
        super.sto.off();
    }
}

3、Invoker：请求者 ----- 持有一个命令对象，有一个行动方法，在某个时间点调用命令对象的 execute() 方法，将请求付诸实行。
----->>这里的Invoker其实就是具体的命令请求方，有点想MVC里的controller用来做总控制，比如RemoteInvoker来作为控制智能家店的命令发起方（即命令的请求者），然后通过上面的Command来请求对应的具体命令，比如控制空调的AirConditionOnCommand或控制音响的StereoOnCommand，最终指向对应的接收者。但是千万不要以为请求者和接收者之间有什么关系！请求方不关心接收方是谁，接收方怎么实现的，实现了没有，什么时候实现的。。。等等都不关心。这也是命令模式的魅力，将发起与接收的耦合降到最低，大大提高了扩展性！
更形象一点的举个例子，一个团队负责开发一个项目，这个项目中只需要出一个人和客户接口，客户也只对这一个接口人提出项目要求。具体项目内如何开发，如何运转，如何实现，客户并不关心，客户只对接口人输出信息。而接口人反过来对项目则按需安排工作，这个接口人就是Invoker，而客户就是下面提到的client。
public class Invoker {
    private Command command
    //客户发出命令
    public void setCommond() {
        this.command = command;
    }
    //执行客户命令
    public void action(){
        this.command.execute();
    }

}

4、Receiver：接收者 ----- 接收者知道如何进行必要的动作，实现这个请求。任何类都可以当接收者。
----->>这里的Receiver就对应的命令落地方，接收方，接收命令的那个实体。比如空调AirCondition或者音响Stereo
//父类Receiver是个抽象类，所有接受者都是该抽象类的子类，为所有接收者的抽象集合
public class Stereo extends Receiver{

    public void on() {
        System.out.println("开启音响");
    }
    public void off() {
        System.out.println("关闭音响");
    }
}

5、Client：客户端 ----- 创建一个具体命令(ConcreteCommand)对象并确定其接收者，包括把其他角色串连在一起。
----->>其实看到这里，就会发现，前面的接受者，请求者，命令，具体命令之间是松耦合的，是没有耦合关联的，所以，我们需要用客户端Client，来组合这些松耦合的模块行程一套整体的命令流程体系。根据不同的需求，在Client中用不同的命令组合去实现，就将这些分散的小伙伴们聚在了一起！
public class RemoteClient {

    public static void main(String[] args) {
		//先定义接口人，就是请求者Invoker
        Invoker boss = new Invoker();
        //下达命令！
        Command command = new StereoOnCommand();
        //接口人收到命令
        boss.setCommand(command);
        //接口人执行命令
        boss.action();
        //看上面代码就可以发现，如果有不同的命令，只需要改下达命令那里的具体命令对象，其余不用变。
        //这样非常的高效
    }
}

2.3 命令模式分析
百度百科对命令模式的分析非常易懂，非常清晰的指出了命令模式的特点：
1.命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开。
2.每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
3.命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
4.命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。
5.命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
2.4 命令模式的优点
1.降低对象之间的耦合度。
2.新的命令可以很容易地加入到系统中，可扩展性非常高！
3.可以比较容易地设计一个组合命令。命令都是对象，组合起来非常方便
4.和其他模式结合可以变得更加好用！
2.5 命令模式的缺点
其实看到这里了，你肯定会有一个疑问，如果窝家里有100个智能家电，平均每个家电都有6个命令，那就会有至少600个命令对象，这将是非常庞大的command类群。当然可以结合模板方法模式来减少command子类膨胀，但依旧需要谨慎使用~

作者：焦振清

时间：2017-11-20

日常工作中，对于之前没有接触过的命令，如何快速有效的学习，每个人可能都有不同的思路，今天，介绍一种比较通用的方法，能够确保大家在短时间内快速掌握一个命令的常用使用方法，并能够快速应用在工作中

第一部分：命令的用途说明
第二部分：单个参数的用法和使用截图
第三部分：组合参数的用法和使用截图
第四部分：实际工作中常见的场景
第五部分：注意事项（对资源的消耗/容易出错的地方）
第六部分：整理考试题目