Talk is Cheap, Show me the Code! <<网站首页文章列表

前言这里只讨论验证码的实现方法，不对验证码的用户体验进行探讨。下面就是今天要讨论的验证码样子：从上图可以看出，这个验证码分为两部分：+ 点击区域（包含文字“猎技公网上科络”，其实就是猎上网络科技）。+ 下方提示区域（包含文字“猎上网络”），提示用户要在点击区域按顺序点击哪些文字。 -------- 点击区域的原始文字分布通过CSS定位，将点击区域的图片展示给用户，通过JS让用户可以在该区域的文字上进行点击和取消点击。 随机定位该区域文字是通过程序进行了随机定位，目的就是打乱顺序，提高识别词组的难度。 随机缩放对所有文字进行了随机的缩放，为了肉眼可辨认，缩放值在一定范围内，再次提高文字识别难度。缩放的原则就是人眼可以快速识别，但是干扰了机器识别。 随机旋转对所有文字在一定角度内进行了旋转，进一步提高识别难度。变形的原则就是，人眼快速识别，但是干扰机器识别。可以进一步对文字进行扭曲等等。 随机颜色对所有文字进行文字前景色的随机，结合背景色的混淆，进一步提高识别难度。 文字识别的干扰还可以对文字区域进行背景图片填充，通过增加像素点的颜色干扰提示识别难度。有时候增加背景图之后，背景图会与随机的文字颜色进行融合，不仅提高了机器识别难度，更增加了肉眼识别难度。因此可以在文字的同坐标下，增加一个与之同缩放同旋转的大一号的浅色相同的文字，作为文字描边。这个描边是在目标文字之下的，所以不会是一个完全描边，但是大大降低了肉眼识别难度。---- 目标文字分布通过CSS定位，将提示区域的图片展示给用户，并在图片前方提示用户“按顺序

零、前言经过文章[《搜索引擎入门——启动第一个Solr应用 》](https://oomabc.com/articledetail?atclidf9b37293ec184ab6ad4d672327057dd7)的介绍，我们已经成功搭建了一个搜索引擎服务。通过使用Solr提供的rest接口，我们已经能够完成索引重建、更新以及查询的功能。本章主要介绍以下几个方面的内容：+ 查询界面的基本使用：基本关键字查询、二次查询、排序、分页、默认查询字段、返回字段设置等等。+ 查询语句的调试：主要是进行关键字查询得分的调试，可以清楚的看到每一个结果所匹配的条件以及详细得分计算情况。+ 关键字高亮与摘要：搜索引擎常见的功能，对命中的关键字进行高亮展示。+ 高级自定义查询：主要是借助solr封装的一些函数进行字段的简单计算，最终干预文档得分。------ 一、基本查询上图是我们项目中使用的一个职位索引的查询页面，这是Solr启动之后我们所要重点关注的查询页面。 普通查询语句 q这个参数可以直接输入关键字，那么它查询的字段就是schema.xml中配置的默认查询字段keyword。关于schema.xml的相关配置可以参考另一篇文章[《搜索引擎入门——聊聊schema.xml配置》](https://oomabc.com/articledetail?atclidadb7b81f31ca4b45b1315b3af89a9c23)。那么，qjava的查询结果与qkeyword:java的查询结果是一样的。这个q里面可以设置任意多组查询条件，比如qpositiontitle:java cityname:上海 functionname:技术，就是搜索上海的技术职能下的java岗位。多组条件可以用AND符号连接，如果都是AND可以用空格代替，系统自动使用defaultOperator配置的连接符。当然我们也可以进行

前言Lucene中一个很重要的概念就是文档（Document），它代表一条建立索引的独立且完整的数据。可以对标到我们关系数据库的一条记录。一个Document包含很多个域（Field），对标数据库的字段Column。Field的一些属性配置对标字段的属性。本身Lucene对Document的Field是开放式的，不同Field的Document可以索引到一起，有点类似于noSQL的概念，属于schema-free的。但是这种开放式结构会造成“开发一时爽，维护骂爹娘”的情况，所以Solr在封装Lucene的时候通过schema.xml文件来规范Document的Field定义。类似于MongoDB的一些ORM框架（Morephia、spring-data-mongo）做的事，其实就是定义一个标准、做个存根，方便排查。所以，schema.xml配置的内容就出来了：+ Field Type 定义：定义了字段类型，string、int、double、text等等，名字是自取的。+ Field 定义：字段，比如positionid、name、age等等。------ schema.xml的大致结构XML -- -- -- positionid keyword 从实际的配置文件也可以发现，schema中确实主要包含两个内容，types和fields。+ types：定义Field类型的元数据。+ fields：表示这个索引的每条

零、关于Solr摘自维基百科： Solr（读作“solar”）是[Apache Lucene](https://zh.wikipedia.org/wiki/Lucene)项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。Solr是高度可扩展的，并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎，Solr 4还增加了NoSQL支持。 Solr是用Java编写、运行在Servlet容器（如[Apache Tomcat](https://zh.wikipedia.org/wiki/ApacheTomcat)或Jetty）的一个独立的全文搜索服务器。 Solr采用了[Lucene](https://zh.wikipedia.org/wiki/Lucene) Java搜索库为核心的全文索引和搜索，并具有类似REST的HTTP/XML和JSON的API。 Solr强大的外部配置功能使得无需进行Java编码，便可对其进行调整以适应多种类型的应用程序。Solr有一个插件架构，以支持更多的高级定制。 因为2010年Apache Lucene和Apache Solr项目合并，两个项目是由同一个[Apache软件基金会](https://zh.wikipedia.org/wiki/Apache%E8%BD%AF%E4%BB%B6%E5%9F%BA%E9%87%91%E4%BC%9A)开发团队制作实现的。提到技术或产品时，Lucene/Solr或Solr/Lucene是一样的。 Solr的历史2004年，Solr作为CNET Networks为公司网站添加搜索功能的一个内部项目，由Yonik Seeley创建。 后来Yonik Seeley随Grant Ingersoll和Erik Hatcher创建了LucidWorks（原名Lucid Imagination），公司提供商业支持、咨询和Apache Solr搜索技术的培训。2006年1月，CNET Networks决定捐赠其到Apache软件基金会顶级项目Lucene，公开发布其源代码。像在Apache软件基金会的任何新项目一样，其进入了一个潜伏期，以助于解决组织、法律和金融问题。2007年1月，Solr结束

java对象结构 HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。 对象头（Header）对象头又可以分为两个部分：MarkWord和Klass+ Markword第一部分markword，用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开指针启压缩）中分别为32bit和64bit，官方称它为“MarkWord”。+ Klass Pointer对象头的另外一部分是Klass类型指针，即对象指向它的类元数据的指针（所以也可以称为元数据指针），虚拟机通过这个指针来确定这个对象是哪个类的实例。所占空间大小为64bit，即8字节（开启指针压缩，大小为4字节）。+ 数组长度（只有数组对象有）如果对象是一个数组, 那在对象头中还必须有一块数据用于记录数组长度。这是一个int类型的数值，所占空间为4字节。 实例数据（Instance Data）这里面包括了对象的所有成员变量，其大小由各个成员变量的大小决定，比如：byte和boolean是1个字节，short和char是2个字节，int和float是4个字节，long和double是8个字节，reference是8个字节（开启指针压缩，reference是4字节）。 静态属性的所占空间不计算在对象内存的大小中，因为它们存放在方法区。 对齐填充（Padding）第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot的虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数（1倍或者2倍），因此当对象实例数据部分没有对齐时，就需要通过对齐填充（P

前言程序设计模式其实是前人在不断探索过程中总结出来的，符合一定的开闭原则并且相对来说足够优雅的代码范式。经历过足够长的项目洗礼，其实用性自然是不用怀疑。既然是在编码过程中衍化而来的范式，那么我辈在开发过程中也会或多或少的用到，或者说自然而然的写出来。所以，关于Java设计模式的介绍，主要是帮大家规范平时的代码。换句话说，帮助大家缩短从自热而然的初窥门径到熟练运用的所花费时间。至于具体的代码，大家其实不用过于在意，关键是领会其思想，解决了什么问题。 关于适配器模式百度百科对适配器一词的解释： 适配器是英语Adapter/adaptor的汉语翻译。适配器就是一个接口转换器，它可以是一个独立的硬件接口设备，允许硬件或电子接口与其它硬件或电子接口相连，也可以是信息接口。比如：电源适配器、三角架基座转接部件、USB与串口的转接设备等。Java的适配器模式中的适配器，也是起到了一个转换的作用，将目前手头有单不匹配的功能接口转换成适用的目标接口。更专业的解释是： 适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。话不多说，下面记录一些我借鉴一些技术文章并结合自己的想法，而进行的一些测试。 电脑电源适配器我先根据我们最常接触的电源适配器来进行抽象，应用下适配器模式。首先定义一个供电电源接口类PowerSource.java：Javapackage designpatterns.adapter.e3;/ @author Smile.Wu @version 2015-10-19 电源接口 /public interface PowerSource { int supplyPower();}定义一

前言在搜索引擎的两个阶段会用到分词功能，分别是索引和查询。先说一下个人在垂直搜索引擎常用的索引分词设置（针对IK分词器）。无论采用何种分词设置，都会有一定的局限性或者说缺陷。因此在合适的阶段选择适合业务场景的分词方式才是最重要的。 索引阶段IK分词器提供了两种分词模式，通过布尔变量useSmart来设置。我在索引阶段设置useSmartfalse，其含义就是采用最小粒度分词，即会分出最多的可能的词汇（包括分词歧义词汇）。比如短语“中华人民共和国”的分词结果就是：中华人民共和国、中华人民、中华、华人、人民共和国、人民、共和国、共和、国。可以看出来，这个模式下分词器会将词库中有的词全部分出来。其中“华人”这个词在短语中属于歧义词，在这个语境中是不合适的。之所以选择这个模式，是因为在索引的时候尽可能的建立更多分词的倒排索引关系链，这与全文检索的“一次索引，多次查询”的特点有关。对于这个短语来说，除了“华人”之外的其它分词能搜索到这个短语，都是合理的场景。 查询阶段我在查询阶段（也就是用户输入关键字查询结果中的分词阶段），设置了useSmarttrue。其含义是IK分词器会用其智能分词功能给你最合适的分词结果，一般来说是词语最少的结果，但是它能最大程度保留原短语的语境含义。比如短语“中华人民共和国”的分词结果就是：中华、人民共和国。这两个词就最大程度保留了语境含义，而且其输入能完美映射到索引阶段。对于，索引中出现“中华”和“人民共和国”两个词语相距很远的情况，可以通过设置查询跨度来过滤。"中华人民共和国"~2，这里的2是指两个双引号之间的短语，各个分词的起始位置之间的最大允许间隔。 在Solr的schema.xml的配置xml

前言 搜索引擎的出现，整合了众多网站信息，恰恰起到了信息导航的作用。通用搜索引擎就如同互联网第一次出现的门户网站一样，大量的信息整合导航，极快的查询，将所有网站上的信息整理在一个平台上供网民使用，于是信息的价值第一次普遍的被众多商家认可，迅速成为互联网中最有价值的领域。互联网的低谷由此演变为第二次高峰。大家熟知的搜索引擎Google、百度、雅虎等是通用搜索引擎现如今的杰出代表，他们为互联网的发展做出了重要的贡献。然而，搜索引擎行业也不是一家公司就可以独撑天下的，从百度的上市、yahoo中国的并购一系列动作表明，如今的搜索引擎大战如同门户网站初期的竞争一样激烈。相信，通用搜索引擎在经历过一段时间的角逐后，也将会继续维持几大服务商各自分控一部分市场的局面。通用搜索引擎的性质，决定了其不能满足特殊领域、特殊人群的精准化信息需求服务。市场需求多元化决定了搜索引擎的服务模式必将出现细分，针对不同行业提供更加精确的行业服务模式。可以说通用搜索引擎的发展为垂直搜索引擎的出现提供了良好的市场空间，势必将出现垂直搜索引擎在互联网中占据部分市场的趋势，也是搜索引擎行业细分化的必然趋势。 垂直搜索引擎是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式，通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”，且具有行业色彩，相比较通用搜索引擎的海量信息无序化，垂直搜索引

Java是一门通用的、支持并发的面向对象的编程语言。它借鉴了C和C++的语法，但是舍弃了一些令它们变得复杂的、不安全的容易使人产生迷惑的特性。而JVM（Java Virtual Machine）则是Java平台的基石。正因为它，Java平台才能使用少量的编译代码就能实现跨硬件、跨操作系统特性，而且让用户免受恶意程序的攻击。虽然是一个虚拟的计算机器，但JVM与真实的物理计算机一样，也有自己的指令集，也会在运行时操作不同的内存区域。通过虚拟机来实现编程语言是很常见的，比如UCSD Pascal语言就是通过P-Code虚拟机实现的。第一个JVM原型是由Sun公司实现的。----- JVM内存结构——运行时数据区（Run-Time Data Areas）JVM规范定义了在程序运行期间的若干个不同的运行时数据区（内存）。有些区域的生命周期与JVM一致，随着JVM的启动而创建，又随着JVM的退出而销毁。有些区域是线程私有的，线程私有的数据区生命周期与线程的生命周期一致。+ 程序计数器（Program Counter Register）+ Java虚拟机栈（Java Virtual Machine Stacks）+ Java堆（Java Heap）+ 方法区（Method Area） + 运行时常量池（Runtime Constant Pool）+ 本地方法栈（Native Method Stacks）--- 程序计数器（Program Counter Register）JVM的能支持多线程并发，就是通过线程轮流切换并分配CPU时间来实现的。每个JVM线程都有各自独立的程序计数器，只有这样才能在多线程轮流切换之后恢复到正确的执行位置。同一时刻，只有一个线程可以执行当前方法对应的机器指令。如果当前执行的不是native方法，则程序计数器的值就是当前正在执行的JVM指令的内

说到搜索引擎，大家都不会陌生，尤其是互联网从业者更是如此。而大部分程序员都能对其基本原理说个七七八八，比如分词、倒排链表、空间向量模型、余弦定理、Top-N......。而且对于全文检索的两个过程索引和查询也都知道个大概。+ 索引：对数据进行分词，然后按照分词结果生成倒排链表（包含词频、位置等信息），最后生成索引文件。+ 查询：对查询语句进行分词，综合其他查询条件生成查询树并优化；对查询树进行倒排链表匹配，将匹配到的链表按照查询语义进行操作（交集、并集、差集等）；最后按照打分规则进行排序并分页返回结果。当然真正的实现细节会复杂许多，比如数据结构、数据类型定义、索引存储、数据压缩、相关链表操作算法、跳跃表、打分模型、内存索引切换等等，都是需要考虑的地方。 链表操作前面介绍的那些内容中，有一个是非常重要而且相对来说比较容易看懂和说明白的就是链表操作。何为链表操作？每个Term后面都挂有一个链表，链表的元素主要包含的内容有元素的DocId（这是Lucene给每个文档的自增编号）、Frequency（这是分词在对应文档中出现的频率）。实际上，每个链表元素就对应一篇当初索引的文档，所以链表操作就是对这些文档进行交集、差集、并集的操作。例，有如下几篇文档： A：机器学习最通俗的解释就是让机器学会决策。 B：支持向量机(SVM)是90年代中期发展起来的基于统计学习理论的一种机器学习方法。 C：随机森林的基本单元是决策树。 D：分类和回归是机器学习解决的两大主要问题。 E：古典决策理论盛行于20世纪初到50年代期间。 F：分类树（决策树）是一种十分常用的分类方法，是一种有监督的机器学习方法。现在我们只考虑其中几个分词，而且暂时忽略分词的歧义性，那么简易

一、什么是类的加载类的加载，就是将.class文件中的二进制数据读取到内存中，其实是存放于运行时的方法区。然后在堆中创建一个java.lang.Class对象（该对象封装了符合方法区定义的数据结构），同时向用户提供访问方法区内的数据结构的接口。JVM允许类加载器对某个类进行预加载。预加载过程发生错误（.class文件缺失或者有错误），类加载器需要在程序首次主动使用该类时报告错误（LinkageError），如果程序一直没有主动使用这个类，则类加载器不会报告这个错误。类加载器的加载方式：本地文件系统、网络.class文件、压缩包中的.class文件、Java源文件动态编译的.class文件。 二、类的生命周期类的生命周期包括加载、验证、准备、解析、初始化五个阶段。其中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的。而解析可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。 加载（Loading）：查找对应目录中的类，并加载二进制字节流 1. 通过classpath和类的完整签名来读取对应的二进制字节流。 2. 将二进制字节流所代表的存储结构转化为方法区的数据结构。 3. 在堆中生成一个代表这个类的java.lang.Class对象，作为访问方法区数据结构的入口。此阶段结束之后，JVM外部的二进制字节流文件就按照规范存储在方法区了，而且堆中存在一个可以访问这些方法区中的数据的对象。 -------- 连接-验证（Linking-Verification）：确保被加载的类的正确性（符合当前虚拟机版本规范，且不会造成危害） 1. 文件格式验证：验证字节流是

AI基础进行中... Zookeeper简介 Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination. ZooKeeper is a high-performance coordination service for distributed applications. It exposes common services - such as naming, configuration management, synchronization, and group services - in a simple interface so you don't have to write them from scratch. You can use it off-the-shelf to implement consensus, group management, leader election, and presence protocols. And you can build on it for your own, specific needs.Apache ZooKeeper致力于提供一个高可用、高性能、开源的分布式应用协调服务。它为分布式应用提供一致性保障，常用的服务包括：命名系统、配置管理、分布式同步、组服务等。你通过一些简单的接口就可以轻而易举的获得一些功能，例如一致性维护、组管理、leader选举；同样的，你可以基于它来实现自己想要的其它功能。 ZooKeeper是以Fast Paxos算法为基础的，Paxos算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有leader才能提交proposer，具体算法可见Fast Paxos。因此，要想弄懂ZooKeeper首先得对Fast Paxos有所了解。 设计目的+ 易用性 ZooKeeper提供一种简单的层级式命名设计，就像我们PC标准的文件系统一样（文件和目录）。通过共享同一个命名目录，ZooKeeper实现多个分布式处理过程之间可以相互通信、协调。 命名空间由数据目录组成，我们称之为zn

本章要介绍的内容是solr中的自定义排序规则，或者说自定义得分函数。看懂本章内容，最好了解过以下知识点：1. solr的基本查询功能2. solr的edismax高级复合查询3. edismax中bf的作用关于solr内置function的用法可以参考官方文档《[Function Queries][solrLink]》，后续如果有机会，我会另出一篇文章加以阐述。---- 需求背景本来搜索服务提供的是一个职位搜索功能，面向的用户是猎头。所以，有一个需求就是按照猎头对每个职位的一个偏好预测值（记为V）进行职位综合排序。每个猎头对于不同的职位都有一个偏好预测值，记为H1V1。这个值由AI团队根据猎头所有行为记录进行统计计算，然后搜索团队要在猎头某一次搜索的结果内进行偏好预测值排序。几万猎头和几万职位的预测值是一个非常庞大的数据集。功能实现方式：1. 在职位索引增加一个动态字段，然后在建索引的时候猎头ID命名动态字段，对应的值就是这个猎头对当前职位的偏好预测值。dmdouble10002100，表示猎头10002对当前职位的偏好预测值为100。然后在搜索的时候，通过猎头id指定字段进行sort即可。2. 自定义一个function，通过solr提供的功能，在搜索时进行实时预测值查询，然后内置排序。方法1确实是一个最简单的方式，非常好理解，就是增加一个动态排序字段，然后sort即可。但是问题是数据量会非常大，而且意义不大。如果有10000个职位，30000个猎头，那么笛卡尔积就是3亿的偏好预测值，平均每个职位上要大约增加30000个动态字段，一个document会变得非常臃肿。当然，可以进行无效数据的预处理等方式进行优化，但是最后的数据依旧会庞大无比，关键是大部分都是无效数据。所以，我采用的是方法2。![图片](https://oomabc.com/staticsrc/img/201812/18/15

前言上一篇[《Java网络编程之Netty学习（二）—— 简单RPC实现 》][prevLink] 简单介绍了如何使用netty实现远程过程调用。不过在很多方面都存在着问题，包括并发性、内存使用、负债均衡、服务发现、服务注册、服务降级。本章以及后续将会出现的章节，旨在逐步解决这些问题，当然解决这些问题的方式、方法都会是自己思考并结合dubbo相关源码。主要是通过这一系列的实践来学习Netty、dubbo等技术框架的应用。本章主要介绍如何通过zookeeper来实现Provider的注册、Counsumer订阅、本地降级。代码都是在本系列前置文章的源码的基础之上修改的，后续会逐步进行代码重构。经整理，本章内容的主要信息点如下：1. 获得provider服务器ip2. Zookeeper客户端curator的使用3. Zookeeper节点监听以及回调4. mock接口本地简单判断--- 知识点介绍 如何获得本机的IP地址这里指的是获得服务器的IP地址，而不是获得请求客户端的IP地址。一般情况下，我们如果想获得客户端的IP地址，通常会从HttpServletRequest对象中获取，比如：java private static final String NGINXIPHEADER "X-Real-IP"; private static final String NGINXXForwardedFor "X-Forwarded-For"; / 功能描述: 获取ip（兼容nginx转发） @param request @return / public static String getIpAddr(HttpServletRequest request) { String ips request.getHeader(NGINXXForwardedFor); String[] ipArray org.apache.commons.lang3.StringUtils.split(ips, ","); if (ArrayUtils.isNotEm

前言本章实现一个最简单的RPC小工具，简单的不能称之为框架。它是在学习Netty框架时的一个简单应用，包含的常规知识点有动态代理、可重入锁、Java反射、序列化。+ 动态代理 根据接口定义，生成一个该接口的一个实现对象，这是一个代理对象。在消费者调用接口的某个方法的时候，我们可以在方法前后增加自定义逻辑。本例中，增加的逻辑就是封装接口信息、方法以及参数信息，然后通过RPC服务类将封装的好的信息传递给生产者，然后将返回结果返回给消费者，完成一个RPC调用过程。+ 可重入锁 通过ReentrantLock以及它的Condition属性对象来实现将Netty的NIO特性转为常规RPC的同步性。 ReentrantLock是一个可重入锁，它与在方法或者代码块上使用synchronized具有相同的并发特性和隐性监视器锁访问语义，不过，它具有更好的扩展性。这个锁被最后获得且未释放它的线程所拥有，一个线程如果尝试去获得一个未被任何线程拥有或者已被自己拥有的锁，都会立即成功。 关于synchronized的隐性监视器锁（参考其它文章）： + 同步方法通过ACCSYNCHRONIZED关键字隐式的对方法进行加锁。当线程要执行的方法被标注上ACCSYNCHRONIZED时，需要先获得锁才能执行该方法。 + 同步代码块通过monitorenter和monitorexit执行来进行加锁。当线程执行到monitorenter的时候要先获得所锁，才能执行后面的方法。当线程执行到monitorexit的时候则要释放锁。 + 每个对象自身维护这一个被加锁次数的计数器，当计数器数字为0时表示可以被任意线程获得锁。当计数器不为0时，只有获得锁的线程才能再次获得锁，所以synchronized也是可重入锁。+ Java反射 Java反射机制可以让我们在编译期（Compile Time）之外的运行期（Runtime）获得任何一个类的字