很久时间没写博客了，并不是没写哦，而是没有再csdn写。。。

语句一
SELECT 
  * 
FROM
  student a,
  score b,
  score c 
WHERE a.`s_id` = b.`s_id` 
  AND a.`s_id` = c.`s_id` ;

语句二和三
SELECT 
  * 
FROM
  student a,
  score b,
  score c 
WHERE a.`s_id` = b.`s_id`  = c.`s_id` ;
---------------------------------------------
SELECT 
  * 
FROM
  student a,
  score b,
  score c 
WHERE (a.`s_id` = b.`s_id` AND c.`s_id`=0) OR (a.`s_id` = b.`s_id` AND c.`s_id`=1) ;

首先我们对比一和二  这两个结果是完全不同的 语句二相当于这样子（a.s_id = b.s_id  ）= c.s_id ;会先执行括号中的语句（其实是个布尔表达式），得到的结果是1或者0，然后再用0或者1去跟c.s_id 对比得到最终的结果，其实语句二跟语句三是等效的

最近在学习得过程中接触到了yarn , 是一个包管理工具,用来替代npm . 下面来总结一下：
yarn有以下3个优点 :
安装速度快 (服务器速度快 , 并且是并行下载)

版本锁定

缓存机制

Yarn语法
npm init                                              ---- yarn init
npm install                                         ---- yarn 
npm install xxx@1.1.1 -g                   ---- yarn global add xxx@1.1.1
npm install xxx@1.1.1 --save            ---- yarn add xxx@1.1.1
npm install xxx@1.1.1 --save-dev     ---- yarn add xxx@1.1.1 --dev
npm uninstall xxx --save(-dev)          ----yarn remove xxx
npm run xxx                                      ---- yarn run xxxx

安装方式: npm install yarn -g
官网: https://yarn.bootcss.com/
以下内容请参考原文：https://blog.csdn.net/qiansg123/article/details/80129453

NPM

npm是Node.js能够如此成功的主要原因之一。npm团队做了很多的工作，以确保npm保持向后兼容，并在不同的环境中保持一致。
npm是围绕着语义版本控制（semver）的思想而设计的，下面是从他们的网站摘抄过来的：
给定一个版本号：主版本号.次版本号.补丁版本号， 以下这三种情况需要增加相应的版本号:
主版本号： 当API发生改变，并与之前的版本不兼容的时候

次版本号： 当增加了功能，但是向后兼容的时候

补丁版本号： 当做了向后兼容的缺陷修复的时候

npm使用一个名为package.json的文件，用户可以通过npm install --save命令把项目里所有的依赖项保存在这个文件里。
例如，运行npm install --save lodash会将以下几行添加到package.json文件中。
"dependencies": {
    "lodash": "^4.17.4"
}

请注意，在版本号lodash之前有个^字符。这个字符告诉npm，安装主版本等于4的任意一个版本即可。所以如果我现在运行npm进行安装，npm将安装lodash的主版本为4的最新版，可能是 lodash@4.25.5（@是npm约定用来确定包名的指定版本的）。你可以在此处查看所有支持的字符：https://docs.npmjs.com/misc/semver。
理论上，次版本号的变化并不会影响向后兼容性。因此，安装最新版的依赖库应该是能正常工作的，而且能引入自4.17.4版本以后的重要错误和安全方面的修复。
但是，另一方面，即使不同的开发人员使用了相同的package.json文件，在他们自己的机器上也可能会安装同一个库的不同种版本，这样就会存在潜在的难以调试的错误和“在我的电脑上…”的情形。
大多数npm库都严重依赖于其他npm库，这会导致嵌套依赖关系，并增加无法匹配相应版本的几率。
虽然可以通过npm config set save-exact true命令关闭在版本号前面使用^的默认行为，但这个只会影响顶级依赖关系。由于每个依赖的库都有自己的package.json文件，而在它们自己的依赖关系前面可能会有^符号，所以无法通过package.json文件为嵌套依赖的内容提供保证。
为了解决这个问题，npm提供了shrinkwrap命令。此命令将生成一个npm-shrinkwrap.json文件，为所有库和所有嵌套依赖的库记录确切的版本。
然而，即使存在npm-shrinkwrap.json这个文件，npm也只会锁定库的版本，而不是库的内容。即便npm现在也能阻止用户多次重复发布库的同一版本，但是npm管理员仍然具有强制更新某些库的权力。
这是引用自shrinkwrap文档的内容：
如果你希望锁定包中的特定字节，比如是为了保证能正确地重新部署或构建，那么你应该在源代码控制中检查依赖关系，或者采取一些其他的机制来校验内容，而不是靠校验版本。
npm 2会安装每一个包所依赖的所有依赖项。如果我们有这么一个项目，它依赖项目A，项目A依赖项目B，项目B依赖项目C，那么依赖树将如下所示：
node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js



这个结构可能会很长。这对于基于Unix的操作系统来说只不过是一个小烦恼，但对于Windows来说却是个破坏性的东西，因为有很多程序无法处理超过260个字符的文件路径名。
npm 3采用了扁平依赖关系树来解决这个问题，所以我们的3个项目结构现在看起来如下所示：
node_modules
- package-A
- package-B
- package-C
-- some-file-name-in-package-c.js

这样，一个原来很长的文件路径名就从./node_modules/package-A/node_modules/package-B/node-modules/some-file-name-in-package-c.js变成了/node_modules/some-file-name-in-package-c.js。
你可以在这里阅读到更多有关NPM 3依赖解析的工作原理。https://docs.npmjs.com/how-npm-works/npm3
这种方法的缺点是，npm必须首先遍历所有的项目依赖关系，然后再决定如何生成扁平的node_modules目录结构。npm必须为所有使用到的模块构建一个完整的依赖关系树，这是一个耗时的操作，是npm安装速度慢的一个很重要的原因。
由于我没有详细了解npm的变化，所以我想当然的以为每次运行npm install命令时，NPM都得从互联网上下载所有内容。
但是，我错了，npm是有本地缓存的，它保存了已经下载的每个版本的压缩包。本地缓存的内容可以通过npm cache ls命令进行查看。本地缓存的设计有助于减少安装时间。
总而言之，npm是一个成熟、稳定、并且有趣的包管理器。
Yarn

Yarn发布于2016年10月，并在Github上迅速拥有了2.4万个Star。而npm只有1.2万个Star。这个项目由一些高级开发人员维护，包括了Sebastian McKenzie（Babel.js）和Yehuda Katz（Ember.js、Rust、Bundler等）。
从我搜集到的情况来看，Yarn一开始的主要目标是解决上一节中描述的由于语义版本控制而导致的npm安装的不确定性问题。虽然可以使用npm shrinkwrap来实现可预测的依赖关系树，但它并不是默认选项，而是取决于所有的开发人员知道并且启用这个选项。
Yarn采取了不同的做法。每个yarn安装都会生成一个类似于npm-shrinkwrap.json的yarn.lock文件，而且它是默认创建的。除了常规信息之外，yarn.lock文件还包含要安装的内容的校验和，以确保使用的库的版本相同。
由于yarn是崭新的经过重新设计的npm客户端，它能让开发人员并行化处理所有必须的操作，并添加了一些其他改进，这使得运行速度得到了显著的提升，整个安装时间也变得更少。我估计，速度提升是yarn受欢迎的主要原因。
像npm一样，yarn使用本地缓存。与npm不同的是，yarn无需互联网连接就能安装本地缓存的依赖项，它提供了离线模式。这个功能在2012年的npm项目中就被提出来过，但一直没有实现。
yarn还提供了一些其他改进，例如，它允许合并项目中使用到的所有的包的许可证，这一点让人很高兴。
一个有趣的事情是，yarn文档的态度开始针对npm发生改变，因为yarn项目变得流行起来。
最开始的yarn公告是这么介绍yarn的安装的：
*最简单的入门方法是运行：

npm install -g yarn

yarn*

现在的yarn安装页面是这么说的：
注意：通常情况下不建议通过npm进行安装。npm安装是非确定性的，程序包没有签名，并且npm除了做了基本的SHA1哈希之外不执行任何完整性检查，这给安装系统程序带来了安全风险。
基于这些原因，强烈建议你通过最适合于你的操作系统的安装方法来安装yarn。
以这种速度发展下去的话，如果yarn要宣布他们自己的registry，让开发者慢慢淘汰npm的话，我们一点都不会感到惊讶。
看起来似乎要感谢yarn，npm终于意识到他们需要更加关注一些大家强烈要求的问题了。当我在审核我之前提到的强烈要求的“离线”功能时，我注意到这个需求正在被积极地修复之中。
pnpm

正如我所提到的，在pnpm的作者Zoltan Kochan发表了“为什么要用pnpm？”之后，我才知道pnpm。https://www.kochan.io/nodejs/why-should-we-use-pnpm.html
我不会介绍太多的细节（因为这篇文章已经发布很久了），但是你可以查看我的最初的帖子来寻找更多的内容，同时在Twitter上加入讨论。
但是
我想指出的是，pnpm运行起来非常的快，甚至超过了npm和yarn。
为什么这么快呢？ 因为它采用了一种巧妙的方法，利用硬链接和符号链接来避免复制所有本地缓存源文件，这是yarn的最大的性能弱点之一。
使用链接并不容易，会带来一堆问题需要考虑。
正如Sebastian在Twitter上指出的那样，他最初是打算在yarn中使用符号链接的，但是由于其他一些原因放弃了它。
同时，正如在Github上拥有2000多个Star那样，pnpm能够为许多人所用。
此外，截至2017年3月，它继承了yarn的所有优点，包括离线模式和确定性安装。
总结

我认为yarn和pnpm的开发人员做了一个惊人的工作。我个人喜欢的是确定性安装，因为我喜欢控制，我不喜欢惊喜。
无论这场竞争的结果是什么，我很感谢yarn在npm的脚下点了一把火，提供了另外一个选择。
我确信yarn是一个更安全的选择，但是pnpm可能是一些测试用例的更好的选择。例如，它可以在运行大量集成测试并希望尽可能快地安装依赖关系的中小型团队中发挥作用。
最后，我认为，npm仍然提供了一个非常有用的解决方案，支持大量的测试用例。大多数开发人员使用原始npm客户端仍然可以做得很好。

对比度：是画面黑与白的比值，也就是从黑到白的渐变层次。比值越大，从黑到白的渐变层次就越多，从而色彩表现越丰富。 　　对比度对视觉效果的影响非常关键，一般来说对比度越大，图像越清晰醒目，色彩也越鲜明艳丽；而对比度小，则会让整个画面都灰蒙蒙的。高对比度对于图像的清晰度、细节表现、灰度层次表现都有很大帮助。在一些黑白反差较大的文本显示、CAD显示和黑白照片显示等方面，高对比度产品在黑白反差、清晰度、完整性等方面都具有优势。相对而言，在色彩层次方面，高对比度对图像的影响并不明显。对比度对于动态视频显示效果影响要更大一些，由于动态图像中明暗转换比较快，对比度越高，人的眼睛越容易分辨出这样的转换过程。对比度高的产品在一些暗部场景中的细节表现、清晰度和高速运动物体表现上优势更加明显。
亮度是指画面的明亮程度，单位是堪德拉每平米(cd/m2)或称nits，也就是“烛光/每平方米”。 需要注意的是，较亮的产品不见得就是较好的产品，显示器画面过亮常常会令人感觉不适，一方面容易引起视觉疲劳，同时也使纯黑与纯白的对比降低，影响色阶和灰阶的表现。因此提高显示器亮度的同时，也要提高其对比度，否则就会出现整个显示屏发白的现象。 　　电视机亮度不要开得太大。亮度过大，一是会加速电视机荧光物质的老化，促使荧光物质过早消耗，缩短电视机的寿命；二是增加耗电量，造成浪费；三是刺激眼睛，致使人们的视力减弱。
参考文章：亮度和对比度有什么区别？

我们在面试的时候，时常被问到如何保证线程同步已经对共享资源的多线程编程。我们当然用同步代码块，同步方法，又或者是用java提供的锁机制来达到对共享资源变量的同步控制。
那么我们什么时候用synchronized,什么时候用lock，以及他们的区别是什么呢；
首先来说synchronized 是Java的关键字，是Java的内置特性，在JVM层面实现了对临界资源的同步互斥访问，通过对对象的头文件来操作，从而达到加锁和释放锁的目的。对象的头文件如下图：


那么synchronized的缺点是啥呢：
1）不能响应中断；
2）同一时刻不管是读还是写都只能有一个线程对共享资源操作，其他线程只能等待
3）锁的释放由虚拟机来完成，不用人工干预，不过此即使缺点也是优点，优点是不用担心会造成死锁，缺点是由可能获取到锁的线程阻塞之后其他线程会一直等待，性能不高。
而lock接口的提出就是为了完善synchronized的不完美的，首先lock是基于jdk层面实现的接口，和虚拟机层面不是一个概念；其次对于lock对象中的多个方法的调用，可以灵活控制对共享资源变量的操作，不管是读操作还是写操作；
lock接口的关系图：


ReentrentLock对象和ReentrentReadWriteLock为我们日常开发中见到和用到比较多的两个类；他们都是可重入的锁，即当同一线程获取到锁之后，他在不释放锁的情况下，可以再次获取到当前已经拿到的锁，只需标记获取到锁的次数加一即可；
下面已ReentrentLock的使用为例，来说明如何对共享变量的控制；要求线程甲和线程乙各自轮询添加数字到list集合中；假设说次数为3次；

package part6.jstack;

import java.util.ArrayList;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * Created by xq on 17/6/26.
 */
public class TestLock {
    private ArrayList<String> arrayList = new ArrayList<>();
    Lock lock = new ReentrantLock();
    public static void main(String[] args) {
        final TestLock test = new TestLock();
        for (int i = 0; i < 3; i++) {

           final Integer count=i;
            new Thread("甲"){public void run() {
                test.insert(Thread.currentThread(),count);
            };}.start();
            new Thread("乙"){public void run() {
                test.insert(Thread.currentThread(),count);
            };}.start();

        }
        test.arrayList.stream().forEach(e->{
            System.out.println(e);
        });
    }

    public void insert(Thread thread,Integer count) {

        lock.lock();
        try {
            //线程获取到了锁
            for (int i = 0; i<5; i++) {
                arrayList.add("第"+count+"次"+"线程"+thread.getName()+i);
            }
        } catch (Exception e) {

        }finally {
            //线程释放锁
            lock.unlock();
        }
    }
}
执行结果如下图：

从结果中可以看出，在一个时刻只能有一个线程获取到锁并执行打印；
那么lock和synchronized的区别对比如下：
1）synchronized 在成功完成功能或者抛出异常时，虚拟机会自动释放线程占有的锁；而Lock对象在发生异常时，如果没有主动调用unLock()方法去释放锁，则锁对象会一直持有，因此使用Lock时需要在finally块中释放锁；
2）lock接口锁可以通过多种方法来尝试获取锁包括立即返回是否成功的tryLock(),以及一直尝试获取的lock()方法和尝试等待指定时间长度获取的方法，相对灵活了许多比synchronized;
3) 通过在读多，写少的高并发情况下，我们用ReentrantReadWriteLock分别获取读锁和写锁来提高系统的性能，因为读锁是共享锁，即可以同时有多个线程读取共享资源，而写锁则保证了对共享资源的修改只能是单线程的。