Jason Zhang

回顾总结 process and thread process是操作系统调度的基本单位，一个程序可以理解为一个进程。 thread是process的子process，是process调度的基本单位。   从调度角度理解process和thread   我们知道操作系统调度的时候是以process为单位的，即当我们的程序是单thread的process时，那在这个process获得cpu的时间片时，这个thread能够获得全部的这个时间片。在内核中，我们维护着一个process的table，来记录每个process的基本信息，根据不同的调度方式来使用这个信息或者不使用。   当一个process拥有多个thread时，如何调度thread呢？  当thread为内核态thread时。  当thread为用户态thread时。 混合实现不做讨论   两种情况则有不同的调度方式。当为内核态的thread时，即此时的thread可以称之为轻量级的process，这个时候内核来维护一个thread table和process table相似。同时操作系统来调度thread，就像调度process一样。当为用户态的线程时，那么操作系统感受不到多个thread的存在，因为此时操作系统调度的对象是process，一个process中有多少个thread他不关心，所以当一个process得到CPU时间片后，他会自己来调度thread。   了解他们两个基本工作方式后，应该清楚这两种线程的主要区别：调度者是谁？各个的优缺点是什么？在JAVA中使用的哪种thread？Golang中goroutine是如何对应到我们操作系统的调度单位上去的？ 调度者。 内核态的thread：内核。 用户态的thread：process 内核态thread的优点：在单个thread进行syscall而阻塞 时（一个线程不可以即运行代码，又能进行syscall），操作系统可以切换到同process中或者其他process下一个可以执行的thread，而不必阻塞，然而用户态的thread在进行syscall时，整个process下的thread都会阻塞。用户态的thread优点是在进行thread切换时消耗非常小，因为他不需要像内核态的thread那样需要陷入一次内核。

Traversal of binary tree is very import when sloving the binary tree problem. Today I will try starting to record the traversal way I met in leetcode or somewhere else. Continuing update... 1. LevelOrder Traversal using Queue. This is a very common traversal case. We use it to record the width of the current level. Plus: Actually is a bfs search in a graph when you replace the left and right node to adjs of a vertex. public class Example { public List<Integer> levelOrderTraversal(TreeNode root) { if (root == null ) return null ; List<Integer> result = new ArrayList<>(); Queue<TreeNode> queue = new LinkedList<>(); queue.offer(root); while (!queue.isEmpty()) { int size = queue.size(); for ( int i = 0 ; i < size; i++) { TreeNode tmp = queue.poll(); System. out .println(tmp. val ); result.add(tmp. val ); if (tmp. left !

操作系统 消息传递作为进程间通信的重要一种，他提供了网络间进程通信的方式。但是相比于管程和信号量等，他具有不稳定性。 需要考的问题简单来说有这么几点 消息传递的不可靠性解决。在网络间传递时，A到B已经发送了消息，B可能没有收到，A要有一种机制可以知道B已经收到了消息。因此，B需要发送一个ACknowledge给A，来保证他已经收到。 消息传递的重复性。在A重复的发送了数据后，如果经过一定的时间后，A没有收到ACK，所以又重复发了一次相同的message，但是经过一段时间后，B收到了两个相同消息，如何进行区分？可以在发送的消息中加入连续的序列来表达不同的消息。 还有许多其他问题，这里直说两个比较普遍的问题。

When we post data that the field exceed the limit, elasticsearch will reject the data which error: {"error":{"root_cause":[{"type":"remote_transport_exception","reason":"[cs19-2][10.200.20.39:9301][indices:data/write/index]"}],"type":"illegal_argument_exception","reason":"Document contains at least one immense term in field=\"field1\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped.  Please correct the analyzer to not produce such terms.  The prefix of the first immense term is You can handle this: 1. you can udpate the mapping part at any time PUT INDEXNAME/_mapping/TYPENAME { "properties" : { "logInfo" : { "type" : "string" , "analyzer" : "keyword" , "ignore_above" : 32766 } } } ignore_above means that we will only keep 32766 bytes 2

Classloader是Java运行时核心机制之一，它解决了我们的.class文件如何被jvm加载的问题。也就是我们的写的源码.java文件被编译成.class字节码后，如何被jvm加载解释。 Java在广义上有三种classloader BootstrapClassLoader 是JVM级别的classloader，使用c/c++来写的。详细解释如何来加载一个bootstrap级别的class文件，哪些class文件是bootstrapclassloader来加载的。 ExtClassLoader  是ExtensionClassLoader，他是AppClassLoader的 ‘父类’，这个父类不是指AppClassLoader extends ExtClassLoader，而是指ExtClassLoader来创建了AppClassloader，后面源码部分可以解释这个关系。 AppClassLoader 这是一般我们自己写的class的classloader，他加载了我们自己写的class，而且同时如果我们有自定义的classloader，那么他也是custom class loader的parent class loader. 他们的加载顺序也是从上往下，即 1->2 ->3。   到这里可能会产生疑问，他们加载的class有何不同？  AppClassLoader是上面说的，他会加载我们自己定义的class，即我们workspace的classpath下的class ExtClassLoader则是加载我们Jdk lib/ext 下的class BootstrapClassLoader是加载 rt.jar、resources.jar、charsets.jar和class等。  那么他们是如何找到lib下这些class文件呢？ 答案是通过环境变量中的一些变量，而这些变量的定义也是通过我们设置的JAVA HOME等来取得。 源码中有这么两个地方解释了这个地方。 ==》 private static String bootClassPath = System.getProperty( "sun.boot.class.path" ); ==》 String

在我们以task为粒度的分布式系统中，需要对数据做checkpoint，以保证task在重启的时候内存中未被消费完的数据可以保存到文件系统中以防止丢失。 在第一个版本中，我们的task默认使用了task的名字作为任务的ID，同时在做checkpoint时使用diskQueue也是使用相同的方式来生成。直到我们碰到一个需要更新task配置的需求后产生了问题。 为了解决任务更新的问题，我们task的做了使用时间戳作为版本管理，简单就是说：在更新一个任务的配置后，version会替换，这时候会生成一个新的task（旧的任务在消费完数据后会被cleanTask的任务给删除掉）来继续。 在过渡期的时候，即新旧task同时在运行的时候，我们做了重启操作，此时两个任务同时执行了checkpoint操作。而bug的原因是在于，task的ID和diskQueue的ID是不相同的！也就是说两个任务虽然new出两个diskQ，但是两个diskQ会同时向一个文件中写数据，这就导致了文件的损坏。 这里的反思是：对于一个Task任务，如果需要和外部的文件或者其他资源交互时，一定需要保证外部的依赖对于每一个task任务都是唯一的。这里以fileSystem为例子，一个task保证对应的是一个file or dir。两种方式：1.使用一个xxx.lock的方式，一个系统如果已经决定对该资源做write／read操作时，就建立一个lock。该系统内部的进程想要同时做操作时可以避免因为上述简单的ID BUG而造成的问题。同时其他系统可以辨识到该文件可能被其他应用程序使用中，他可以针对这种情况做一些预期内的操作。 Golang中突然想起一种方案，对于需要写文件或者其他资源访问时，使用一个 channel 来做串行处理。比如当多个不可预知的任务可能同时做一个写入文件操作时，任务可以将此次操作的metadata以一种特定的数据格式交给上层系统（我们定义的channel）来统一处理，因为channel的并发写入是绝对安全的。当然如果是需要对多个文件做写入操作时，我们可以使用这样一种方式： 一个channel对应下游有多个channel（而不是file对象），每个channel都定义一个唯一ID，作为suffix。每个channel写完的文件都有ID，比如A，B，C三个channel现在

我的代码: public Node flatten(Node head){ if(head==null) return null; Node tree = head.right; if(head.left!=null){ head.right = head.left; head.left = null; head = flatten(head.right); } if (tree!=null) { head.right = tree head = flatten(head.right); } return head; }