简栈

Shadowsocks PAC规则

ShadowSocks默认使用GFWList规则和使用adblock plus的引擎。要想自己添加自定义的用户规则，最好熟悉一下其规则：

中文版：Adblock Plus过滤规则

自定义代理规则的设置语法与GFWlist相同，语法规则如下：

• 通配符支持。
  • 比如 *.example.com/*
  • 实际书写时可省略 * ， 如.example.com/ 和 *.example.com/* 效果一样
• 正则表达式支持。
  • 以 \ 开始和结束， 如 \[\w]+:\/\/example.com\
• 例外规则 @@
  • 如 @@*.example.com/* 满足 @@ 后规则的地址不使用代理
• 匹配地址开始和结尾 |
  • 如 |http://example.com 、 example.com| 分别表示以 http://example.com 开始和以 example.com 结束的地址
• ||标记
  • 如 ||example.com 则 http://example.com 、https://example.com 、 ftp://example.com 等地址址满足条件。
• 注释 !
  • 如 !我是注释
• 分隔符^
  • 表示除了字母、数字或者 _ - . % 之外的任何字符。如 http://example.com^ ，http://example.com/ 和 http://example.com:8000/ 均满足条件，而 http://example.com.ar/ 不满足条件。

什么是PAC

• 维基百科摘录的关于PAC的解释：
  • 代理自动配置（英语：Proxy auto-config，简称PAC）是一种网页浏览器技术，用于定义浏览器该如何自动选择适当的代理服务器来访问一个网址。
  • 一个PAC文件包含一个JavaScript形式的函数FindProxyForURL(url, host)。
  • 这个函数返回一个包含一个或多个访问规则的字符串。
  • 用户代理根据这些规则适用一个特定的代理其或者直接访问。
  • 当一个代理服务器无法响应的时候，多个访问规则提供了其他的后备访问方法。
  • 浏览器在访问其他页面以前，首先访问这个PAC文件。
  • PAC文件中的URL可能是手工配置的，也可能是是通过网页的网络代理自发现协议（Web Proxy Autodiscovery Protocol）自动配置的。
• 源自网络的图解：

简单说来，PAC就是一种配置规则，它能让你的浏览器智能判断哪些网站走代理，哪些不需要走代理。

pac.txt

init-method方法

init-method方法，初始化bean的时候执行，可以针对某个具体的bean进行配置。init-method需要在applicationContext.xml配置文档中bean的定义里头写明。例如：

1

<bean id="TestBean" class="nju.software.xkxt.util.TestBean" init-method="init"></bean>

这样，当TestBean在初始化的时候会执行TestBean中定义的init方法。

afterPropertiesSet方法

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

public interface InitializingBean {

	/**
	 * Invoked by the containing {@code BeanFactory} after it has set all bean properties
	 * and satisfied {@link BeanFactoryAware}, {@code ApplicationContextAware} etc.
	 * <p>This method allows the bean instance to perform validation of its overall
	 * configuration and final initialization when all bean properties have been set.
	 * @throws Exception in the event of misconfiguration (such as failure to set an
	 * essential property) or if initialization fails for any other reason
	 */
	void afterPropertiesSet() throws Exception;

}

afterPropertiesSet方法，初始化bean的时候执行，可以针对某个具体的bean进行配置。afterPropertiesSet 必须实现 InitializingBean接口。实现 InitializingBean接口必须实现afterPropertiesSet方法。

BeanPostProcessor类

BeanPostProcessor，针对所有Spring上下文中所有的bean，可以在配置文档applicationContext.xml中配置一个BeanPostProcessor，然后对所有的bean进行一个初始化之前和之后的代理。BeanPostProcessor接口中有两个方法： postProcessBeforeInitialization和postProcessAfterInitialization。 postProcessBeforeInitialization方法在bean初始化之前执行， postProcessAfterInitialization方法在bean初始化之后执行。

前置后置处理器

前言

通过我之前的Tomcat系列文章，相信看我博客的同学对Tomcat应该有一个比较清晰的了解了，在前几篇博客我们讨论了Tomcat在SpringBoot框架中是如何启动的，讨论了Tomcat的内部组件是如何设计以及请求是如何流转的，那么我们这篇博客聊聊Tomcat的异步Servlet，Tomcat是如何实现异步Servlet的以及异步Servlet的使用场景。

手撸一个异步的Servlet

我们直接借助SpringBoot框架来实现一个Servlet,这里只展示Servlet代码：

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
32

@WebServlet(urlPatterns = "/async",asyncSupported = true)
@Slf4j
public class AsyncServlet extends HttpServlet {

    ExecutorService executorService =Executors.newSingleThreadExecutor();

    @Override
     protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        //开启异步,获取异步上下文
        final AsyncContext ctx = req.startAsync();
        // 提交线程池异步执行
        executorService.execute(new Runnable() {


            @Override
            public void run() {
                try {
                    log.info("async Service 准备执行了");
                    //模拟耗时任务
                    Thread.sleep(10000L);
                    ctx.getResponse().getWriter().print("async servlet");
                    log.info("async Service 执行了");
                } catch (IOException e) {
                    e.printStackTrace();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                //最后执行完成后完成回调。
                ctx.complete();
            }
        });
    }

上面的代码实现了一个异步的Servlet,实现了doGet方法注意在SpringBoot中使用需要再启动类加上@ServletComponentScan注解来扫描Servlet。既然代码写好了，我们来看看实际运行效果。

我们发送一个请求后，看到页面有响应，同时，看到请求时间花费了10.05s,那么我们这个Servlet算是能正常运行啦。有同学肯定会问，这不是异步servlet吗？你的响应时间并没有加快，有什么用呢？对，我们的响应时间并不能加快，还是会取决于我们的业务逻辑，但是我们的异步servlet请求后，依赖于业务的异步执行，我们可以立即返回，也就是说，Tomcat的线程可以立即回收，默认情况下，Tomcat的核心线程是10，最大线程数是200,我们能及时回收线程，也就意味着我们能处理更多的请求，能够增加我们的吞吐量，这也是异步Servlet的主要作用。

异步Servlet的内部原理

了解完异步Servlet的作用后，我们来看看，Tomcat是如何是先异步Servlet的。其实上面的代码，主要核心逻辑就两部分，final AsyncContext ctx = req.startAsync()和 ctx.complete()那我们来看看他们究竟做了什么？

当Leader崩溃或者Leader失去大多数的Follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个正确的状态。Zookeeper中Leader的选举采用了三种算法：

• LeaderElection
• FastLeaderElection
• AuthFastLeaderElection

并且在配置文件中是可配置的，对应的配置项为electionAlg。

背景知识

Zookeeper Server的状态可分为四种：

• LOOKING：寻找Leader
• LEADING：Leader状态，对应的节点为Leader。
• FOLLOWING：Follower状态，对应的节点为Follower。
• OBSERVING：Observer状态，对应节点为Observer，该节点不参与Leader选举。

成为Leader的必要条件： Leader要具有最高的zxid；当集群的规模是n时，集群中大多数的机器（至少n/2+1）得到响应并follow选出的Leader。

心跳机制：Leader与Follower利用PING来感知对方的是否存活，当Leader无法相应PING时，将重新发起Leader选举。

术语

zxid：zookeeper transaction id, 每个改变Zookeeper状态的操作都会形成一个对应的zxid，并记录到transaction log中。 这个值越大，表示更新越新。

Zookeeper使用了一种称为Zab（Zookeeper Atomic Broadcast）的协议作为其一致性的核心。Zab协议是Paxos协议的一种变形，下面将展示一些协议的核心内容。

考虑到Zookeeper的主要操作数据状态，为了保证一致性，Zookeeper提出了两个安全属性：

• 全序（Total Order）：如果消息A在消息B之前发送，则所有Server应该看到相同结果。
• 因果顺序（Causal Order）：如果消息A在消息B之前发生（A导致了B），并且一起发送，则消息A始终在消息B之前被执行。

为了保证上述两个安全属性，Zookeeper使用了TCP协议和Leader。通过使用TCP协议保证了消息的全序的特性（先发先到），通过Leader解决了因果顺序(先到Leader先执行)。因为有了Leader，Zookeeper的架构就变成为：Master-Slave模式，但在该模式中Master（Leader）会Crash，因此，Zookeeper引入Leader选举算法，以保证系统的健壮性。

当Zookeeper Server收到写操作，Follower会将其转发给Leader，由Leader执行操作。Client可以直接从Follower上读取数据，如果需要读取最新数据，则需要从Leader节点读取，Zookeeper设计的读写比大致为2：1。

Leader执行写操作可以简化为一个两段式提交的transaction：

1. Leader发送proposal给所有的Follower。
2. 收到proposal后，Follower回复ACK给Leader，接受Leader的proposal.
3. 当Leader收到大多数的Follower的ACK后，将commit其proposal。

在这个过程中，proposal的确认不需要所有节点都同意，如果有2n+1个节点，那么只要有n个节点同意即可，也就是说Zookeeper允许n个节点down掉。任何两个多数派必然有交集，在Leader切换（Leader down）时，这些交集依然保持着最新的系统状态。如果集群节点个数少于n+1个时，Zookeeper将无法进行同步，也就无法继续工作。

Zab与Paxos

背景

对于JVM这块儿的知识，我估计大部分的都是只有在需要面试的时候才会拿出来复习一下，然后就又放下来。也是因为这块儿是Java最底层的部分，非常难懂。其实如果真的说认真、细心的去撸一下，了解透彻，应该就不会那么容易忘记。

今天的主要目的也是根据Oracle的官方文档来一步一步的理解与学习，并且用用一些demo来验证理论。

Java虚拟机内存结构

我们先来看一下JVM一个大概的物理结构图（请注意，不叫内存模型）：

堆的划分

我们首先看一下官方地址对于运行时数据区域的一个划分：https://docs.oracle.com/javase/specs/jvms/se8/html/index.html

2.5. Run-Time Data Areas

• 2.5.1. The pc Register
• 2.5.2. Java Virtual Machine Stacks
• 2.5.3. Heap
• 2.5.4. Method Area
• 2.5.5. Run-Time Constant Pool
• 2.5.6. Native Method Stacks

前言

最近线上出现了JVM 频繁FGC的问题，查询了很多GC相关的资料，做了一些整理翻译。文章比较长可以收藏后慢慢阅读。

一、什么是垃圾回收？(Garbage Collection)

一个垃圾回收器有一下三个职责

• 分配内存
• 确保有引用的对象能够在内存中保留。
• 能够在正在执行的代码环境中回收已经死亡对象的内存。

这里提到的有引用是指存活的对象,后面会提到一些算法用来判断对象是否存活。不在有引用的对象将被认为是死亡的，也就是常说的垃圾garbage。找到并释放这些垃圾对象占用的空间的过程就被称作是垃圾回收garbage collection。

垃圾回收可以解决很多内存分配的问题，但并不意味这全部。 比如：你可以不断地创建对象并保持对它们的引用直到没有可用的内存分配。垃圾回收本身就是一项非常复杂和消耗资源的过程。

二、理想的垃圾收集器需要哪些特性？

1. 垃圾收集器必须是安全和全面的。这就意味着，存活的对象绝对不能被释放，相反垃圾对象在很少的垃圾回收循环里必须被回收。
2. 垃圾回收必须是高效的，不允许出现正在运行的程序长时间暂停。
3. 内存碎片整理，垃圾被收集以后内存会存在很多不连续的内存碎片，可能导致大对象无法分配到足够连续的内存。
4. 扩展性，在多处理器系统、多线程应用中，内存分配和垃圾收集不能成为性能瓶颈。

三、设计选择

对象拷贝有哪些

对象拷贝(Object Copy)就是将一个对象的属性拷贝到另一个有着相同类类型的对象中去。在程序中拷贝对象是很常见的，主要是为了在新的上下文环境中复用对象的部分或全部数据。

Java中有三种类型的对象拷贝：

• 浅拷贝(Shallow Copy)
• 深拷贝(Deep Copy)
• 延迟拷贝(Lazy Copy)

理解浅拷贝

什么是浅拷贝？

• 浅拷贝是按位拷贝对象，它会创建一个新对象，这个对象有着原始对象属性值的一份精确拷贝。

  • 如果属性是基本类型，拷贝的就是基本类型的值；如果属性是内存地址（引用类型），拷贝的就是内存地址 ，因此如果其中一个对象改变了这个地址，就会影响到另一个对象。

  • 在上图中，SourceObject有一个int类型的属性 “field1”和一个引用类型属性”refObj”（引用ContainedObject类型的对象）。当对SourceObject做浅拷贝时，创建了CopiedObject，它有一个包含”field1”拷贝值的属性”field2”以及仍指向refObj本身的引用。由于”field1”是基本类型，所以只是将它的值拷贝给”field2”，但是由于”refObj”是一个引用类型, 所以CopiedObject指向”refObj”相同的地址。因此对SourceObject中的”refObj”所做的任何改变都会影响到CopiedObject。

如何实现浅拷贝

下面来看一看实现浅拷贝的一个例子

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

public class Subject {
 
   private String name; 
   public Subject(String s) { 
      name = s; 
   } 

   public String getName() { 
      return name; 
   } 

   public void setName(String s) { 
      name = s; 
   } 
}

前言

Java是一个安全的编程语言，它能最大程度的防止程序员犯一些低级的错误（大部分是和内存管理有关的）。但凡是不是绝对的，使用Unsafe程序员就可以操作内存，因此可能带来一个安全隐患。

这篇文章是就快速学习下sun.misc.Unsafe的公共API和一些有趣的使用例子。

Unsafe 实例化

在使用Unsafe之前我们需要先实例化它。但我们不能通过像Unsafe unsafe = new Unsafe()这种简单的方式来实现Unsafe的实例化，这是由于Unsafe的构造方法是私有的。Unsafe有一个静态的getUnsafe()方法，但是如果天真的以为调用该方法就可以的话，那你将遇到一个SecurityException异常，这是由于该方法只能在被信任的代码中调用。

1
2
3
4
5
6

public static Unsafe getUnsafe() {
    Class cc = sun.reflect.Reflection.getCallerClass(2);
    if (cc.getClassLoader() != null)
        throw new SecurityException("Unsafe");
    return theUnsafe;
}

那Java是如何判断我们的代码是否是受信的呢？它就是通过判断加载我们代码的类加载器是否是根类加载器。

我们可是通过这种方法将我们自己的代码变为受信的，使用jvm参数bootclasspath。如下所示：

1

java -Xbootclasspath:/usr/jdk1.7.0/jre/lib/rt.jar:. com.mishadoff.magic.UnsafeClient

但这种方式太难了

Volatile简介

volatile被称为轻量级的synchronized，运行时开销比synchronized更小，在多线程并发编程中发挥着同步共享变量、禁止处理器重排序的重要作用。建议在学习volatie之前，先看一下Java内存模型《什么是Java内存模型？》，因为volatile和Java内存模型有着莫大的关系。

Java内存模型

在学习volatie之前，需要补充下Java内存模型的相关(JMM)知识，我们知道Java线程的所有操作都是在工作区进行的，那么工作区和主存之间的变量是怎么进行交互的呢，可以用下面的图来表示。

Java通过几种原子操作完成工作区内存和主存的交互

1. lock：作用于主存，把变量标识为线程独占状态。
2. unlock：作用于主存，解除变量的独占状态。
3. read：作用于主存，把一个变量的值通过主存传输到线程的工作区内存。
4. load：作用于工作区内存，把read操作传过来的变量值储存到工作区内存的变量副本中。
5. use：作用于工作内存，把工作区内存的变量副本传给执行引擎。
6. assign：作用于工作区内存，把从执行引擎传过来的值赋值给工作区内存的变量副本。
7. store：作用于工作区内存，把工作区内存的变量副本传给主存。
8. write：作用于主存，把store操作传过来的值赋值给主存变量。

这8个操作每个操作都是原子性的，但是几个操作连着一起就不是原子性了！

volatile原理

上面介绍了Java模型的8个操作，那么这8个操作和volatile又有着什么关系呢。

volatile的可见性