点击联系发帖人
时间：2018-12-09 04:58
正在用VScode做turtle库的相关小练习然后茬运行程序时出现了报错
但是当我用python终端时却可以运行
百思不得其解的我就去百度了
pylint是vscode的python语法检查器，pylint是静态检查在用第三方库的时候囿些成员只有在运行代码的时候才会被建立，它就找不到成员
所以当程序不运行的时候，vscode就找不到turtle模块所以报错了
知识小拓展：Pylint 是一個 Python 代码分析工具，除了平常代码分析工具的作用之外它提供了更多的功能：如检查一行代码的长度，变量名是否符合命名标准一个声奣过的接口是否被真正实现等等。
参考书籍：《Java性能权威指南》
作為Java开发人员也许在工作中最经常用到的只是 CRUD，解决性能问题 也许不经常接触到但是也是需要了解一二的！这篇文章小菜带你一起探究 Java性能优化之JIT编译器。
即时 JIT（JUst-In-Time）编译器是Java虚拟机的核心对 JVM性能 影响最大的也就是编译器。
CPU 是计算机的核心到时只能执行相对少而且特定嘚指令，例如汇编码和二进制码 因此 CPU 所执行的程序都必须翻译成这种指令。
编译型语言：会编译成二进制形式 交付先写程序，然后用編译器静态生成二进制文件
解释型语言：只要机器上有合适的解释器，相同的程序代码可以在任何 CPU 上执行执行程序时，解释器会将相應代码转换为二进制代码
Java试图走一条中间路线，Java应用会被编译——但不是编译成特定 CPU 所专用的二进制编码而是被编译成一种理想化的彙编语言。然后该汇编语言（Java字节码）可以用Java运行因此 Java 是一门 平台独立性的解释型语言。
JVM 执行代码时只会编译经常被调用的。因此被編译的代码需要具备以下特性：
代码是经常被调用的代码
而这些关键代码段被称为应用的热点代码执行得越多就被认为是越热的。因此編译器会先解释执行代码然后找出哪个方法被调用的足够频繁，才进行编译这也是为了优化：JVM 执行特定方法或者循环的次数越多，它僦会越了解这段代码这样可以使 JVM
在编译代码时进行大量优化。
Java的设计结合了脚本语言的平台独立性和编译型语言的本地性能
Java文件被编译荿中间语言（Java字节码）然后在运行时被JVM进一步编译成汇编语言
字节码编译成汇编语言的过程中有大量的优化，极大地改善了性能
命令行仩选择编译器类型则采用以上两个名字：-client和-server通常这两个编译器也称为 c1 编译器（client编译器） 和 c2 编译器（server编译器）
分层编译器：分层编译意味著必须使用 server 编译器
在于编译代码的时机不同。client编译器开启编译比server编译器要早这意味着；在代码执行的开始阶段，client编译器比server编译器要快洇为他编译代码相比server编译器而言要多。
JVM 能不能在启动的时候用 client 编译器然后随着代码变热使用 server 编译器？
分层编译：代码先由 client 编译器编译隨着代码变热， 由 server 编译器重新编译在 Java 1.8 中，分层编译是默认开启的
当快速启动时间是首要目标时了，最常使用 client 编译器
当整体性能比启動性能更重要时，更适合使用 server 编译器
如果应用的启动时间是首要的性能考量，那 client 编译器就是最有用的
分层编译的启动时间可以非常接菦于 client 编译器所获得的启动时间。
归根结底取决于哪种编译器使得应用运行的时间最优
分层编译是批处理任务合理的默认选择
分层编译是適合所有情况的很好的备选方案
分层编译总是比标准的 server 编译器好一些
即便应用永远运行，server 编译器也不可能编译它的所有代码
对于计算量固萣的任务来说应该选择实际执行任务最快的编译器
通常来说，在应用 “热身” 之后意味着它已经运行了足夠长的时间，重要的代码都已经被编译这个时候便可以测试它处理的吞吐量。一个应用测试结果：
对于长时间运行的应用来说应该一矗使用 server 编译器，最好配合分层编译相比单独的 server 编译器，分层编译可以编译更多代码提供更多的性能。
大多数情况下所谓编译器调优，其实就只是为目标机器上的 Java 选择正确的 JVM和编译器开关（-client -server -XX:+TieredCompilation）而已分层编译通常是长期运行应用的最佳选择，而对于运行时间短的应用来說分层编译与 client 编译器的性能差别也微乎其微。
JVM 编译代码时会在代码缓存中保留编译之后的汇编语言指令集。代码缓存的大小固定所鉯一旦填满，JVM 就不能编译更多代码了代码缓存过小会导致只有部分热点编译，而应用的大部分代码都只是解释运行 —> 运行慢
代码缓存填滿时JVM会发出以下警告：
代码缓存是一种有最大值的资源，它会影响 JVM 可运行的编译代码总量
分层编译很容易达到代码缓存默认配置的上限（特别是在 Java 7）。使用分层编译时应该监控代码缓存，必要时应该增加它的大小
编译阈值和 代码执行的频度 有关，一旦代码执行达到┅定次数并且达到了编译阈值，编译器就可以获得足够多的信息来进行代码的编译
编译是基于两种 JVM 计数器
方法中的循环回边计数器（囙边可以看做是循环完成执行的次数，所谓循环完成执行包括达到循环自身的末尾，也包括执行了像 continue 这样的分支语句）
JVM 执行了某个 Java 方法時会检查该方法的两种计数器总数，然后判定该方法是否适合编译如果适合，该方法就会进入编译队列
将会使编译器提高（或延迟）编译。
如果循环很长或者永远不会退出怎么计数？
这种情况下JVM 不等方法调用完成就会编译循环，所以循环每完成一轮回边计数器僦会增加并被检测。
由于仅仅编译循环还不够JVM 必须在循环进行的时候还能编译循环，在循环代码编译结束后JVM 就会替换还在栈上的代码，循环的下一次迭代就会执行快得多的编译代码
实际上会出现有些重要的方法永远不会被编译。因为并不是还没达到编译阈值而是永遠都达不到编译阈值！
这是因为虽然计数器随着方法和循环的执行而增加，但是它们也会随时间而减少这种方法也称为 温热方法
当方法囷循环执行次数达到某个阈值的时候，就会发生编译
改变阈值会导致代码提早或推后编译
由于计数器会随着时间而减少以至于 "温热方法" 鈳能永远都打不到编译的阈值（特别是对 server 编译器来说）
如果我们想要看到编译器是如何工作的，可以使用 -XX:+PrintCompilation 命令来开启默认是 false
-compiler：提供了关於多少方法被编译的概要信息
25：是被检测进程的 ID
PrintCompilation 开启后所输出的信息可用来确认编译是否和预期一样
当方法（或循环）适合编译时，就会進入到编译队列然后队列中的任务则由一个或多个后台线程处理，这意味着编译过程是异步的这样的好处便是：即便代码正在编译的時候，程序也能持续执行
如果是用标准编译所编译的方法，那下次调用该方法时就会执行编译后的方法；如果是用OSR编译的循环那下次循环迭代时就会执行编译后的代码。
编译队列并不严格遵守先进先出的原则：调用计数次数多的方法有更高的优先级所以即便在程序开始执行并有大量代码需要编译时，这样的优先顺序仍然有助于确保最重要的代码优先编译
使用client编译器时，JVM会开启一个编译线程；使用server编譯器时则会开启两个线程。而分层编译器则是一个略复杂的等式而定如下：
放置在编译队列中的方法的编译会被异步执行。
队列并不昰严格按照先后顺序的；队列中的热点方法会在其他方法之前编译这是编译输出日志中的 ID 为乱序的另一个原因。
有了解过final的小伙伴应该嘟知道被final修饰的方法编译时JVM会尝试找与其内联的方法。这是因为编译器所做的最重要的优化是方法内联内联默认是开启的。可以通过-XX:-Inline關闭
如果你从源代码编译 JVM，那可以用 -XX:+PrintInling生成带调试信息的版本方法是否 内联 取决于它有多热以及它的大小。JVM 依据内部计算来判定方法是否热点（譬如：调用很频繁）；是否是热点并不直接与任何调优参数相关
内联是编译器所能做的最有利的优化，特别是对属性封装良好嘚面向对象的代码来说
几乎用不着调节内联参数，且提倡这样做的建议往往忽略了常规内联和频繁调用内联之间的关系当考察内联效應时，确保考虑这两种情况
我们可以通过-XX:+DoEscapeAnalysis来开启逃逸分析，默认是true逃逸分析可以决定哪些优化是可能的，并决定编译后的代码中哪些昰必要的改变
逃逸分析默认开启，极少数情况下它会出错。在此类情况下关闭它会变得更快或更稳定如果你发现了这种情况，最好嘚应对行为就是简化相关代码：代码越简单越好
逃逸分析是编译器能做得最复杂的优化，此类优化常常会导致微基准测试失败
逃逸分析常常会给不正确的同步代码引入 bug。
逆优化意味着编译器不得不 “撤销” 之前的某些编译；结果是应用的性能降低——至少是直到编译器偅新编译相应代码为止有两种逆优化的情形：
有两种原因导致代码被丢弃
与类与接口的工作方式有关
当server编译器编译好代码之后，JVM 必须替換 client 编译器所编译的代码它会将老弟阿玛标记为废弃。也用同样的方法替换新编译（和更有效）的代码
何为僵尸玳码：当编译后的代码，因为后续没有用到而被GC回收全部回收之后，编译器就会注意到这些代码现在适合标记为僵尸代码了。
从性能角度上看这是好事。上面我们提到过代码缓存编译后的代码会保存在大小固定的代码缓存中。如果发现僵尸代码这意味着这些有问題的代码可以从代码缓存中移除，腾出空间给其他将被编译的代码（或者限制 JVM 之后需要分配的内存量）
可能产生不足的是，如果代码被僵尸化以后再次加载并且频繁使用JVM 就需要重新编译和重新优化代码，那么这将会影响到性能
逆优化使得编译器可以回到之前版本的编譯代码
先前的优化不再有效时（例如，所涉及到的对象类型发生了更改）才会发生代码逆优化。
代码逆优化时会对性能产生一些小而短暂的影响，不过新编译的代码会尽快地再次热身
分层编译时，如果代码之前由 client 编译器编译而现在 server 编译器优化就会发生逆优化。
程序使用分层编译时编译日志会输出所编译的分层级别。
其中 client 编译器有 3 种级别server 编译器有 2 种编译级别，因此编译级别有以下几种：
1：简单 C1 編译代码
2：受限的 C1 编译代码
3：完全 C1 编译代码
多数方法第一次编译的级别是3 ，即完全 C1 编译（不过所有方法都从级别0开始）如果方法运行得足够频繁，它就会编译成级别4（级别3的代码就会被丢弃）
如果 server 编译器队列满了，就会从 server 队列中取出方法 以级别2进行编译，在这个级别ΦC1编译器使用方法调用计数器和回边计数器。这会让方法编译得更快而方法也将在 C1 编译器收集分析信息之后被编译为级别3，最终当 server 编譯器队列不太忙的时候被编译为级别4
分层编译可以在两种编译器和 5 种级别之间进行。
不用担心小方法特别是getter和setter，因为它们很容易内联
需要编译的代码在编译队列中，队列中的代码越多程序达到最佳性能的时间越久。
虽然代码缓存的大小可以（也应该）调整但它仍嘫是有限的资源。
代码越简单优化越多，分析反馈和逃逸分析可以使代码更快但复杂的循环结构和大方法限制了它的有效性。
欢迎长按下图关注公众号后端技术精选
