金融项目微调OpenJDK，编译源码 系统版本：Ubuntu 16.04 LTS系统类型：64位操作系统编译出来的是64位的JDK，可以通过设置参数--with-target-bits=32生成32位编译结果。OpenJDK源码下载 https://hg.openjdk.java.net/jdk8/jdk8，点击左侧zip下载到到本地直接解压即可。微调源码使该JDK编译打包后的jar其他JDK无法识别，应用系统必须和JDK配套部署，例如银行自己开发的一套企业金融资产管理系统，交付第三方财务公司使用时，同时提供jar包和JDK，这样就增强了系统的安全性。安装GCC或CLang，例如，安装GCC的命令为：sudo apt-get install build-essential在编译过程中需要依赖FreeType、CUPS等若干第三方库，OpenJDK全部的依赖库如下：OpenJDK除了使用C、C++编写外，还使用了Java语言，因此还需要一个编译期可用的小版本JDK（如JDK7），官方称为“Bootstrap JDK”。编译命令：1.执行bash configure --enable-debug --with-jvm-variants=serverconfigure会检查依赖项、参数配置和构建输出目录结构等。2.执行make images编译整个OpenJDK，images（product-images）是编译出整个JDK镜像，其他参数还有：hotspot：只编译HotSpot虚拟机 hotspot-<variant>：只编译特定模式的Hot Spot虚拟机 docs-image：产生JDK的文档镜像 test-image：产生JDK的测试镜像 all-images：相当于连续调用product、docs、test三个编译目标 bootcycle-images：编译两次JDK,其中第二次使用第一次的编译结果作为Bootstrap JDK clean：清理make命令产生的临时文件 dist-clean：清理make和configure命令产生的临时文件编译后产生的JDK路径：build/配置名称/jdk，把它复制到JAVA_HOME目录，就可以作为一个完整的JDK来使用。重新编译前先执行make clean和makedist-clean命令清理目录。

Memcache部署流程 建安装目录 mkdir -p /application/search/libeventmkdir -p /application/search/memcached安装libevent tar zxvf libevent-2.0.21-stable.tar.gzcd libevent-2.0.21-stable./configure -prefix= /application/search/libeventmakemake installtar zxvf memcached-1.4.21.tar.gz注：安装memcached时需要指定libevent的安装位置./configure -prefix=/application/search/memcached --with-libevent=/application/search/libeventmakemake instal启动memcached/application/search/memcached/bin/memcached -d -m 1024 -u search -l 172.16.0.6 -p 12015 -c 512 -P/application/search/searcher/memcached/bin/memcached 可执行程序路径11211 端口号1024m 分配1024M内存-d 在后台运行Memcached在实现分布集群部署时，Memcached服务端的之间是没有通讯的，服务端是伪分布式，实现分布式是由客户端实现的，客户端实现了分布式算法把数据保存到不同的Memcached 服务端。分布式缓存需考虑如下三点：1、缓存本身的水平线性扩展的问题。2、缓存大病罚下的本身性能问题。3、避免缓存的单点鼓掌问题。分布式缓存存在的问题：1、内存本身的管理问题。内存的分配，管理和回收机制。2、分布式管理和分布式算法。3、缓存键值管理和路由。

Linux免密登陆-ubuntu 1.假设目前有2台服务器：Master、Slave，现在要设置它们之间免密码ssh登陆。2.1 配置Master免密码登陆Slave免密码ssh登录的原理是这样的：a.Master（NameNode | JobTracker）如果作为客户端，实现无密码公钥认证，来连接到服务器Salve（DataNode | Tasktracker）上，需要在Master上生成一个密钥对，包括1个公钥和1个私钥，然后需要将公钥复制到所有的Slave上。b.当Master通过SSH连接Salve时，Salve就会生成一个随机数，并且用Master的公钥对随机数进行加密，并且发送给Master。c.Master收到加密数之后，会使用自己的私钥解密，并将解密数回传给Slave。d.Slave确认解密数无误之后就允许Master进行连接了。这就是一个公钥认证过程，这个过程中不需要用户手动输入密码。而具体到实现这个无密码登录的准备过程，重要的是将客户端Master的公钥复制到Slave上。2.1.1 创建“.ssh”目录若“.ssh目录”不存在，创建”.ssh目录”：mkdir ~/.ssh2.1.2 修改“.ssh 目录”权限。chmod 700 ~/.ssh2.1.3 创建Master服务器的公钥和私钥ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa这个过程会在目录：~/.ssh/下生成公钥：id_rsa和私钥：id_rsa.pub2.1.4 配置Master本机ssh免密登录做测试同第1步类似，在Master上配置一下本机的ssh免密登录，将公钥“id_rsa.pub”追加到授权的key里面：cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys授权：chmod 0600 ~/.ssh/authorized_keys然后使用命令：ssh localhost做测试，没问题就可以了。注意： 登陆之后，记得执行：exit退出！2.1.5 修改SSH配置文件"/etc/ssh/sshd_config"修改SSH配置文件：/etc/ssh/sshd_config确保以下内容信息：RSAAuthentication yes # 启用 RSA 认证PubkeyAuthentication yes # 启用公钥私钥配对认证方式AuthorizedKeysFile .ssh/authorized_keys # 公钥文件路径（和上面生成的文件同）2.1.6 拷贝Master的公钥到Slave上去执行命令：scp ~/.ssh/id_rsa.pub hadoop@Slave:~/2.1.7 配置Slave节点登录Slave节点，执行以下操作：a.修改.ssh权限：chmod 700 ~/.sshb.把Master的公钥追加到Slave的授权文件"authorized_keys"中去：cat ~/id_rsa.pub >> ~/.ssh/authorized_keysc.修改该授权文件的权限：chmod 600 ~/.ssh/authorized_keys2.1.8 测试免密码登录在Master上执行：ssh Slave其中“Slave”已经在Master的“/etc/hosts”文件中配置过了，如果这个登录不需要输入密码，那么免密码ssh登录就设置成功了！2.2 配置Slave免密码登陆Master

“锁”相关总结 synchronized 1.JDK 6之后，synchronized目前锁一共有4种状态，级别从低到高依次是：无锁、偏向锁、轻量级锁和重量级锁。锁状态只能升级不能降级。偏向锁，一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。轻量级锁，是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。重量级锁，若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。重量级锁，除了拥有锁的线程以外的线程都阻塞。{lamp/}ReentrantLock Synchronized，Java虚拟机完成，不公平锁，ReentrantLock和synchronized都是可重入锁。ReentrantLock，类层面的实现，户自己去操作，可以指定锁是公平的还是非公平的。NonReentrantLock，不可重入锁。ReentrantLock更灵活，在Hashtable和ConcurrentHashMap中体现得淋漓尽致synchronized的话，锁的范围是整个方法或synchronized块部分；而Lock因为是方法调用，可以跨方法，灵活性更大。和synchronized相比，ReentrantLock提供给用户多种方法用于锁信息的获取，比如可以知道lock是否被当前线程获取、lock被同一个线程调用了几次、lock是否被任意线程获取等等。ReentrantLock的某些方法可以决定多长时间内尝试获取锁，如果获取不到就抛异常，这样就可以一定程度上减轻死锁的可能性，如果锁被另一个线程占据了，synchronized只会一直等待，很容易错序死锁。之后，synchronized做了诸多优化，效率上synchronized和ReentrantLock应该是差不多。{lamp/}公平锁 VS 非公平锁 公平锁：线程直接进入队列中排队，等待队列中除第一个线程以外的所有线程都会阻塞，优点是等待锁的线程不会饿死，缺点是整体吞吐效率相对非公平锁要低。非公平锁：如果此时锁刚好可用，线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程，缺点是处于等待队列中的线程可能会饿死，或者等很久才会获得锁。{lamp/}乐观锁 VS 悲观锁 {lamp/}自旋锁 VS 适应性自旋锁 自旋锁：自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。适应性自旋锁：自适应意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。{lamp/}可重入锁 VS 非可重入锁 可重入锁，又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。{lamp/}独享锁 VS 共享锁 ReentrantLock和ReentrantReadWriteLock{lamp/}volatile 当写一个volatile变量时，JMM会把该线程对应的本地内存中的变量强制刷新到主内存中去，导致其他线程中的缓存无效。volatile是一种轻量级的同步机制，一是保证共享变量对所有线程的可见性；二是禁止指令重排序优化。volatile对于单个的共享变量的读/写具有原子性，但是像num++这种复合操作，volatile无法保证其原子性。可以用num.incrementAndGet()。

Zookeeper学习笔记 节点选举 Zookeeper节点状态有looking following leading。①每个server首先给自己投票（myid，ZXID，epoch），将这个投票发给集群中其他机器（epoch选举周期，每次进入新一轮的投票后，都会对该值进行加1操作）②每个server接受来自各个服务器的投票，检查是否是本轮投票、是否来自LOOKING状态的服务器③处理投票优先检查ZXID。ZXID比较大的服务器优先作为Leader如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器④统计投票每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，一旦选出leader，后边的机器不管myid和ZXID多大，都自动成为follow⑤改变服务器状态{lamp/}Znode Znode数据节点，数据大小不能超过1M，分为持久节点和临时节点，临时节点的生命周期和客户端会话绑定，一旦客户端会话失效节点就会被移除。创建节点时还可以指定SEQUENTIAL属性，这样会在节点后面增加一个自增的整型数字。节点信息包含czxid创建该节点的事务id、mzxid最后一次更新该节点的事务id等。Zookeeper将数据存储于内存中，Znode是存储数据的最小单元，而Znode被以层次化的结构进行组织，形容一棵树，这种节点称为Znode：data：Znode存储的数据信息。ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。stat：包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。{lamp/}应用场景 ①.数据发布订阅：配置信息等放到Zookeeper某个节点上，集群中其他机器监听变更。②.负载均衡：动态感知子节点（即服务ip）的上下线。③.命名服务：持久顺序节点，每个父节点都会为子节点维护一个顺序，数字后缀、上限为整型的最大值。④.分布式协调和通知：同a。⑤.集群管理：每个机器一个临时节点。⑥.Master选举：所有服务同时创建一个节点并监测，成功的为Master。⑦.分布式锁：排它锁（一起去创建和监听临时节点）、共享锁（创建临时序号节点，比本序号小的序号没有写请求时，才可以写）。⑧.分布式队列。{lamp/}其他 ①.ZAB协议原子消息广播协议，分为消息广播、崩溃恢复。②.基于观察者模式设计，数据的状态发生变化，Zookeeper就通知已经在Zookeeper上注册的那些观察者做出相应的回应。③.Zookeeper的数据结构和linux的目录结构类似，也像数据结构中的树。