Posts

基础命令 查看有那些镜像 xxxxx:5000/v2/_catalog 查看具体项目的tag列表 xxxx:5000/v2/project/repo/tags/list 启动一个镜像 docker run -it --rm -v $PWD:/tmp -w /tmp self_image_name self_command 其中 -v: 将宿主的目录挂载到容器内部 -w: 指定工作目录 启动一个镜像(web应用，需要端口映射) docker run -it --rm -v $PWD:/tmp -w /tmp -p 5000:5000 self_image_name self_command 查看容器内部的标准输出 docker logs -f bf08b7f2cd89 查看容器内部运行的进程 docker top wizardly_chandrasekhar 查看容器的配置和状态信息 docker inspect wizardly_chandrasekhar 更新镜像 docker commit -m="has update" -a="runoob" e218edb10161 runoob/ubuntu:v2 打tag（push到仓库） docker tag 860c279d2fec runoob/centos:dev docker login xxxx.com docker push a/b/c/image_name:v1.0.0 GPU 环境安装 NVIDIA Docker 安装 如需在 Linux 上启用 GPU 支持，请安装 NVIDIA Docker 支持 验证 nvidia-docker 安装效果...

HTTP协议发展历史 HTTP0.9 1991年发布。该版本极其简单，只有一个命令GET，不支持请求头 HTTP/1.0 1996年5月发布。引入请求头和响应头；新增请求方法，如head/post HTTP1.1 1997年1月发布。支持长连接；添加Content-Length字段；分块传输编码等 SPDY 2012年Google发布。HTTP2.0就是基于SPDY设计的，现在已经无人使用。添加多路复用（Multiplexing）；header压缩（DEFLATE算法）；服务端推送等 HTTP2.0 2015年发布。本文主要讲解内容，后文详细讨论。 HTTP3.0 2018年发布。尚未研究，不在本文讨论范围。 HTTP/2 的wiki介绍，可以看下定义和发展历史。RFC 7540 定义了 HTTP/2 的协议规范和细节, RFC 7541定义了头部压缩。如果有时间，最后就直接看RFC的文档。没有什么资料可以比官方文档写的更清楚。本文只是自已的归纳和整理。难免有些粗陋和错误，望评判指正。 一、HTTP2 解决什么问题 HTTP2的提出肯定是为了解决HTTP1.1已经存在的问题。所以HTTP1.1存在那些问题呢？ 1.1 TCP连接数限制 因为并发的原因一个TCP连接在同一时刻可能发送一个http请求。所以为了更快的响应前端请求，浏览器会建立多个tcp连接，但是第一tcp连接数量是有限制的。现在的浏览器针对同一域名一般最多只能创建6~8个请求；第二创建tcp连接需要三次握手，增加耗时、cpu资源、增加网络拥堵的可能性。所以，缺点明显。 1.2 线头阻塞 (Head Of Line Blocking) 问题 每个 TCP 连接同时只能处理一个请求 - 响应，浏览器按 FIFO 原则处理请求，如果上一个响应没返回，后续请求 - 响应都会受阻。为了解决此问题，出现了 管线化 - pipelining 技术，但是管线化存在诸多问题，比如第一个响应慢还是会阻塞后续响应、服务器为了按序返回相应需要缓存多个响应占用更多资源、浏览器中途断连重试服务器可能得重新处理多个请求、还有必须客户端 - 代理 - 服务器都支持管线化。 1.3 Header 内容多 每次请求 Header不会变化太多，没有相应的压缩传输优化方案。特别是想cookie这种比较长的字段 对于HTTP1.1存在的这些问题，是有一定的优化方案的，比如用对个域名，文件合并等。但是这些毕竟比较麻烦，甚至无聊。 二、基本概念 数据流: 已建立的连接内的双向字节流，可以承载一条或多条消息。 消息: 与逻辑请求或响应消息对应的完整的一系列帧。 帧: HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。 这些概念的关系总结如下: 所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。 每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。 每条消息都是一条逻辑 HTTP 消息（例如请求或响应），包含一个或多个帧。 帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 标头、消息负载等等。 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。 三、HTTP2特性有那些 需要强调的是HTTP/2 是对之前 HTTP 标准的扩展，而非替代。 HTTP 的应用语义不变，提供的功能不变，HTTP 方法、状态代码、URI和标头字段等这些核心概念也不变。 我们已经知道http1....

磁盘扇区大小：512B 影响硬盘性能的因素 寻道时间：3-15ms 旋转延迟：7200rpm的硬盘大约为60*1000/7200/2=4.17ms 数据传输耗时：IDE/ATA（133MB/s）, SATA(300MB/s) 硬盘分区首先被划分为一个个的Block，一个Ext2文件系统上的每个Block都是一样大小的，Ext2文件系统中所支持的Block大小有1K、2K、4K三种。在格式化时Block的大小就固定了，且每个Block都有编号，方便Inode的记录。每个Block内最多只能够放置一个文件的数据，如果文件大于Block的大小，则一个文件会占用多个Block；如果文件小于Block，则该Block的剩余容量就不能够再被使用了，即磁盘空间会浪费 扇区和block的关系： 操作系统读取硬盘的时候，不会一个个扇区地读取，这样效率太低，而是一次性连续读取多个扇区，即一次性读取一个"块"（block）。这种由多个扇区组成的"块"，是文件存取的最小单位。“块"的大小，最常见的是4KB，即连续八个 sector组成一个 block。

一、java concurrent包下lock类图概览 红色连线的表示内部类  1、java并发包下面的锁主要就两个，ReentrantLock（实现Lock接口） 和ReentrantReadWriteLock（实现ReadWriteLock接口）。 2、ReentrantLock类构造函数如下, sync是Sync的实例，NonfairSync（非公平锁）和FairSync(公平锁)是Sync的子类。 public ReentrantLock() { sync = new NonfairSync(); } public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); } 3、ReentrantReadWriteLock类构造函数如下，共有三个属性，sync、readerLock、writerLock public ReentrantReadWriteLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); readerLock = new ReadLock(this); writerLock = new WriteLock(this); } 我们看到ReentrantLock和ReentrantReadWriteLock都的实现都依赖于sync这个对象。sync是AbstractQueuedSynchronizer的实例。AbstractQueuedSynchronizer就是java并发包下面实现锁和线程同步的基础，AbstractQueuedSynchronizer就是大名鼎鼎的AQS队列，下文我们都用AQS来表示AbstractQueuedSynchronizer。 ##二、ReentrantLock实现原理 1、如何加锁 ReentrantLock使用方式如下 class X { private final ReentrantLock lock = new ReentrantLock(); // ... public void m() { lock....

java并发包已经存在Reentrant锁和条件锁，已经可以满足很多并发场景下线程安全的需求。但是在大量读少量写的场景下，并不是最优的选择。与传统锁不同的是读写锁的规则是可以共享读，但只能一个写。很多博客中总结写到读读不互斥，读写互斥，写写互斥。就读写这个场景下来说，如果一个线程获取了写锁，然后再获取读锁（同一个线程）也是可以的。锁降级就是这种情况。但是如果也是同一个线程，先获取读锁，再获取写锁是获取不到的（发生死锁）。所以严谨一点情况如下： 项目 非同一个线程 同一个线程 读读 不互斥 不互斥 读写 互斥 锁升级（不支持），发生死锁 写读 互斥 锁降级（支持），不互斥 写写 互斥 不互斥 读写锁的主要特性： 公平性：支持公平性和非公平性。 重入性：支持重入。读写锁最多支持 65535 个递归写入锁和 65535 个递归读取锁。 锁降级：遵循获取写锁，再获取读锁，最后释放写锁的次序，如此写锁能够降级成为读锁。 ReentrantReadWriteLock java.util.concurrent.locks.ReentrantReadWriteLock ，实现 ReadWriteLock 接口，可重入的读写锁实现类。在它内部，维护了一对相关的锁，一个用于只读操作（共享锁），另一个用于写入操作（排它锁）。 ReentrantReadWriteLock 类的大体结构如下： /** 内部类 读锁 */ private final ReentrantReadWriteLock.ReadLock readerLock; /** 内部类 写锁 */ private final ReentrantReadWriteLock.WriteLock writerLock; final Sync sync; /** 使用默认（非公平）的排序属性创建一个新的 ReentrantReadWriteLock */ public ReentrantReadWriteLock() { this(false); } /** 使用给定的公平策略创建一个新的 ReentrantReadWriteLock */ public ReentrantReadWriteLock(boolean fair) { sync = fair ?...