Nginx

前言九月旺季已经来临，曾经何时，在17年的九月，经过再三考虑，我决定跳出一份干了四年且比较安逸的开发工作，当时下定决心，选择跳槽。最后跟着诸多农码一起涌进了一段为期两个月的面试高峰期。但是在选择跳出后，好多人都问我：“阿光，现在不是做的好好的么，怎么突然间就选择离职了，再说了，现在外面的工作也不好找啊，而且在这里薪资也还不错，为啥要走？”当时，面对这样的问题，我只用了几个字给回复他们了：“我是做开发的，但现在的工作不是我想像的那种，我不要在每天做哪些业务代码了，我要跳出舒适区，我要迎接新的挑战。”在这狂热的九月里，我的简历投了无数个，也面试好几家不错的一线互联网公司，但最后都没有面上，最后，还是无意间通过一个群的渠道，认识了几位大牛，最后报名，获取内推机会，最后经过努力，成功面入狗厂。算起来我还是挺幸运的。现在也是九月，现在回味起来，那时候面试的路上也是蛮艰辛的。最近这几天我抽空整理了一下17年的面试经验，相信这些面试经验对那些想跳出舒适区，近期想换工作的码农们，这些面试经验，希望对你们有所帮助。——后面我还总结了我的工作心得。源码分析真题你有没有用过Spring的AOP? 是用来干嘛的? 大概会怎么使用？说说你对Java注解的理解什么是依赖注入？什么是控制反转(IOC)？ 在 Spring 中，有几种依赖注入方式？工厂模式你知道哪几种？你用过哪几种？每一种的用法知道么？在 Spring 中，有几种配置 Bean 的方式？SpringMVC中RequestMapping可以指定GET, POST用法么？怎么指定？SpringMVC如果希望把输出的Object(例如XXResult或者XXResponse)这 种包装为JSON输出, 应该怎么处理?分布式真题1、说说HashMap和Hashtable的区别 2、说一下实现一个保证迭代顺序的HashMap3、说一说排序算法，稳定性，复杂度4、说一说GC5、JVM如何加载一个类的过程，双亲委派模型中有哪些方法？6、 TCP如何保证可靠传输？三次握手过程？7、你们用什么Redis客户端? Redis高性能的原因大概可以讲一些?8、你熟悉哪些Redis的数据结构? zset是干什么的? 和set有什么区别?微服务真题1、什么是微服务？你知道有哪些框架？用过哪些框架？2、springCloud和dubbo 有哪些区别？3、什么是微服务熔断？什么是服务降级？4、springboot和springcloud，请你谈谈对他们的理解？5、你所知道的微服务技术栈有哪些？请列举一二6、说说 RPC的实现原理7、说说 Dubbo的实现原理并发编程真题1、并发了解么？说说看你对并发的理解2、什么是线程？线程和进程有什么区别？如何在Java中实现线程？3、死锁与活锁的区别，死锁与饥饿的区别？4、你知道在java中守护线程和本地线程区别么，说说你的看法？5、Java中用到的线程调度算法是什么？性能优化真题1、JVM内存分哪几个区，每个区的作用是什么?2、如和判断一个对象是否存活?(或者GC对象的判定方法)3、简述java垃圾回收机制?4、java中垃圾收集的方法有哪些?5、如何自定义一个类加载器？你使用过哪些或者你在什么场景下需要一个自定义的类加载器吗？6、做gc时，一个对象在内存各个Space中被移动的顺序是什么？7、你有没有遇到过OutOfMemory问题？你是怎么来处理这个问题的？处理 过程中有哪些收获？上面就是我的面试笔记记录，这几个面试点应该是面试比较喜欢问的了，特别是分布式和JVM这些，如果想进大厂且薪资高的话，这两个知识点是必学要弄清楚的。还有就是你的个人见解了，这些都是非常重要的了。废话不多说，大家往下看我的近期总结学习心得，继续往下看干货………..（如果想和作者一样系统化的学习面试真题后面的架构体系图，大家可以加文章末尾的群号，里面有学习资料，加群备注即可领取。我只能帮你们到这里了。我也在群里，希望和大家共同学习进步。）程序员应有的几个阶段第一阶段—-三年我认为三年对于程序员来说是第一个门槛，这个阶段将会淘汰掉一批不适合写代码的人。这一阶段，我们走出校园，迈入社会，成为一名程序员，正式从书本上的内容迈向真正的企业级开发。我们知道如何团队协作、如何使用项目管理工具、项目版本如何控制、我们写的代码如何测试如何在线上运行等等，积累了一定的开发经验，也对代码有了一定深入的认识，是一个比较纯粹的Coder的阶段。第二阶段—-五年五年又是区分程序员的第二个门槛。有些人在三年里，除了完成工作，在空余时间基本不会研究别的东西，这些人永远就是个Coder，年纪大一些势必被更年轻的人给顶替；有些人在三年里，除了写代码之外，还热衷于研究各种技术实现细节、看了N多好书、写一些博客、在Github上分享技术，这些人在五年后必然具备在技术上独当一面的能力并且清楚自己未来的发展方向，从一个Coder逐步走向系统分析师或是架构师，成为项目组中不可或缺的人物。第三阶段—-十年十年又是另一个门槛了，转行或是继续做一名程序员就在这个节点上。如果在前几年就抱定不转行的思路并且为之努力的话，那么在十年的这个节点上，有些人必然成长为一名对行业有着深入认识、对技术有着深入认识、能从零开始对一个产品进行分析的程序员，这样的人在公司基本担任的都是CTO、技术专家、首席架构师等最关键的职位，这对于自己绝对是一件荣耀的事，当然老板在经济上也绝不会亏待你。我认为，随着你工作年限的增长、对生活对生命认识的深入，应当不断思考三个问题：我到底适不适合当一名程序员？我到底应不应该一辈子以程序员为职业？我对编程到底持有的是一种什么样的态度，是够用就好呢还是不断研究？最终，明确自己的职业规划，对自己的规划负责并为之努力。如何成为一名优秀的程序员1.愿意学习新技术随着技术的不断进步，我们学到和实施的技术会很快地过时。所以，作为一个程序员，你就需要更新你的技能，保持与时俱进。市场上出现的所谓新技术通常由一些进程和语法变化而构成，但逻辑是相通的，所以你可以很快地掌握它。2.调试技巧程序员不但需要创建代码，而且当软件不按预期方式工作时，程序员还必须能够快速而有效地解决问题。因此，与其更改所有代码，还不如在创建程序时制作适当的流程文档，以便你可以快速检查代码并尽快找到问题。制作正确的文档可以方便你快速调试程序，而不浪费时间。3.解决问题的技巧当一名普通的程序员获得项目/模块时，他们会直接写代码。但一名成功的程序员会试图找出代码出现问题的根源，并通知团队领导或项目负责人。因为有时在文档化项目需求并启动项目后，或者甚至在完成项目后，我们才会在项目中遇到一些问题。所以最好在出现问题之前先找到问题。此外，快速地找到解决问题的方法。4.对工作的热情我们的工作时间大多为朝九晚五，但是当你对工作迸发激情时，那么不要到了休息日就将工作束之高阁。一直工作直到完成它。当然，我的意思不是说如果你没有解决方案，还得成天垂头丧气对着电脑，我的意思是如果你已经接近于完成的时候，那么索性一鼓作气搞定吧。你的经理或高层将会欣赏你的工作，并且当你有一个良好的环境时，你的激情将会越发高昂。另外，在没有工作的时候也不要无所事事。不妨尝试构建一些新的应用程序，如游戏，拼图，聊天应用程序等，这将有助于使你更加热爱你的工作。5.懒惰…我的意思是更高效！当有很多任务并且快没有时间来完成项目的时候，这时只有懒惰的程序员才能找到更好和最快的解决方案，因为他非常了解如何才能事半功倍。如果你想找到做事的最好方式，那么就去问懒惰的人；很多时候这些所谓的懒人会找到最好、最快和最有效的方法，因为他们总在试图寻找更高效的路径方法。在此我向大家推荐一个架构学习交流群。交流学习群号：478030634 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多大家觉得文章对你还是有一点点帮助的，大家可以点击下方二维码进行关注。 《乐趣区》 公众号聊的不仅仅是Java技术知识，还有面试等干货，后期还有大量架构干货。大家一起关注吧！关注烂猪皮，你会了解的更多…………..

注意：本文为转载，原文链接：Windows下PHP服务nginx不能使用file_get_contents/curl/fopen的原因！一、问题说明在Windows环境下搭建了一个本地开发服务环境，使用Nginx做服务，但是在使用file_get_contents()获取本地的链接时http://127.0.0.1/index.php，出现了这样的错误：file_get_contents(http://127.0.0.1/index.php) [<a href=‘function.file-get-contents’>function.file-get-contents</a>]: failed to open stream: HTTP request failed! 本地电脑php环境为：nginx+php+mysql；于是找到这篇文章做个笔记，记录下！这两天一直在搞windows下nginx+fastcgi的file_get_contents请求。我想，很多同学都遇到当file_get_contents请求外网的http/https的php文件时毫无压力，比如echo file_get_contents(‘http://www.baidu.com’) ，它会显示百度的页面。但当你请求localhost/127.0.0.1本地网络的php服务时却一直是timeout，无论你将请求时间和脚本运行时间多长都无法返回数据，如file_get_contents(‘http://localhost/phpinfo.php’) 。然而当你尝试请求html这样的静态文件时却完全没有问题。是什么原因呢？！首先，我们知道file_get_contents/curl/fopen打开一个基于tcp/ip的http请求时，请求数据发送到nginx，而nginx则委托给php-cgi(fastcgi)处理php文件，一般情况fastcgi处理完一个php请求后会马上释放结束信号，等待下一个处理请求（当然也有程序假死，一直占用资源的情况）。打开nginx.conf，我们看到下面这一行：location ~ .php { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME d:/www/htdocs$fastcgi_script_name; include fastcgi_params;}上面已经清楚地看到，所有使用php结尾的文件都经过fastcgi处理，而在php.ini的配置文件中也有一句：cgi.force_redirect = 1表明，所有php程序安全地强制转向交给cgi处理。但在windows中，本地127.0.0.1:9000怎样与php-cgi联系的呢？！答案是增加一个php-cgi进程，用它来监听127.0.0.1:9000。通过控制器命令：RunHiddenConsole.exe D:/www/php/php-cgi.exe -b 127.0.0.1:9000 -c C:/WINDOWS/php.ini我们就可以在启动windows时，开启一个php-cgi.exe进程监听来自127.0.0.1:9000 的请求。在dos命令下打开netstat –a就可以看到本地计算机下的9000端口处于listening状态（也就是空置，如果没有发送任何请求的话）。好了，该说说在php中使用file_get_contents()、curl()、fopen()函数访问localhost时为什么不能返回结果。我们再来试验在index.php中加入file_get_contents(‘http://127.0.0.1/phpinfo.php’) 语句向phpinfo.php发送一个请求，这时浏览器中的状态指示一直在打转，表示它一直在工作中。打开Dos中的netstat命令，可以看到本地的9000端口的状态为：ESTABLISHED，表示该进程在联机处理中。实际上，这里我们已经同时向nginx发送了两个基于http的php请求，一个是解析index.php，而另一个是phpinfo.php，这样矛盾就出来了，因为我们的windows系统只加载了一个http进程，因此，它无法同时处理两个php请求，它只能先处理第一个请求（index.php），而index.php却又在等待phpinfo.php处理结果，phpinfo.php没人帮它处理请求，因为它一直在等待index.php释放结束信号，因此，造成了程序的阻塞状态，陷入了死循环。所以我们就看到了浏览器的状态指示一直在打转。Curl()与fopen函数的原因也相同。二、解决方法找到了原因，我们也就有了解决办法。一是，向系统增加一个http请求，当一个php-cig内要加载另一个请求时，它能够分配其它http处理额外的php请求。这时需给另一个http sever分配不同的端口，比如8080。nginx的案例如下：http { server { listen 80; server_name 127.0.0.1; location / { index index.php; root /web/www/htdocs; } } server { listen 8080; server_name 127.0.0.1; location / { index index.html; root /web/www/htdocs; } } include /opt/nginx/conf/vhosts/php.conf; }这样，端口80与8080可以分别处理不同的程序，比如：test.php echo file_get_contents(‘http://localhost:8080/phpinfo.php’);当然，在*unix下有更多选择，比如fork。另外提醒下，网上有人说，通过去掉地址中的http://协议标记，而使用相对地址就规避函数的检查，实际情况是不是这样呢？！当在index.php中使用file_get_contents(‘phpinfo.php’); 时，我们可以看到函数输出了phpinfo.php的源代码，相当于file_get_contents(‘file:c:wwwphpinfo.php’); ，它实际上只是读取你的文本内容，因为file_get_contents()函数首先是处理file协议的，而curl则直接报错无法解析。因此这些人纯粹是不学无术的骗子。还有人提出修改hosts文件，增加localhost www.xxx.com影射关系，函数通过www.xxx.com访问本地php，这其实也是不治本的偏方，因为这只是方便计算机的dns解析，最终www.xxx.com交给127.0.0.1，而后者交给唯一http，还是阻塞。 ...

Golang Gin实践 连载十七 用 Nginx 部署 Go 应用原文地址：Golang Gin实践 连载十七 用 Nginx 部署 Go 应用前言如果已经看过前面 “十六部连载，两部番外”，相信您的能力已经有所提升那么，现在今天来说说简单部署后端服务的事儿 ????做什么在本章节，我们将简单介绍 Nginx 以及使用 Nginx 来完成对 go-gin-example 的部署，会实现反向代理和简单负载均衡的功能Nginx是什么Nginx 是一个 Web Server，可以用作反向代理、负载均衡、邮件代理、TCP / UDP、HTTP 服务器等等，它拥有很多吸引人的特性，例如：以较低的内存占用率处理 10,000 多个并发连接（每10k非活动HTTP保持活动连接约2.5 MB ）静态服务器（处理静态文件）正向、反向代理负载均衡通过OpenSSL 对 TLS / SSL 与 SNI 和 OCSP 支持FastCGI、SCGI、uWSGI 的支持WebSockets、HTTP/1.1 的支持Nginx + Lua安装请右拐谷歌或百度，安装好 Nginx 以备接下来的使用简单讲解常用命令nginx：启动 Nginxnginx -s stop：立刻停止 Nginx 服务nginx -s reload：重新加载配置文件nginx -s quit：平滑停止 Nginx 服务nginx -t：测试配置文件是否正确nginx -v：显示 Nginx 版本信息nginx -V：显示 Nginx 版本信息、编译器和配置参数的信息涉及配置1、 proxy_pass：配置反向代理的路径。需要注意的是如果 proxy_pass 的 url 最后为/，则表示绝对路径。否则（不含变量下）表示相对路径，所有的路径都会被代理过去2、 upstream：配置负载均衡，upstream 默认是以轮询的方式进行负载，另外还支持四种模式，分别是：（1）weight：权重，指定轮询的概率，weight 与访问概率成正比（2）ip_hash：按照访问 IP 的 hash 结果值分配（3）fair：按后端服务器响应时间进行分配，响应时间越短优先级别越高（4）url_hash：按照访问 URL 的 hash 结果值分配部署在这里需要对 nginx.conf 进行配置，如果你不知道对应的配置文件是哪个，可执行 nginx -t 看一下$ nginx -tnginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is oknginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful显然，我的配置文件在 /usr/local/etc/nginx/ 目录下，并且测试通过反向代理反向代理是指以代理服务器来接受网络上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。（来自百科）配置 hosts由于需要用本机作为演示，因此先把映射配上去，打开 /etc/hosts，增加内容：127.0.0.1 api.blog.com配置 nginx.conf打开 nginx 的配置文件 nginx.conf（我的是 /usr/local/etc/nginx/nginx.conf），我们做了如下事情：增加 server 片段的内容，设置 server_name 为 api.blog.com 并且监听 8081 端口，将所有路径转发到 http://127.0.0.1:8000/ 下worker_processes 1;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 8081; server_name api.blog.com; location / { proxy_pass http://127.0.0.1:8000/; } }}验证启动 go-gin-example回到 go-gin-example 的项目下，执行 make，再运行 ./go-gin-exmaple$ makegithub.com/EDDYCJY/go-gin-example$ lsLICENSE README.md conf go-gin-example middleware pkg runtime vendorMakefile README_ZH.md docs main.go models routers service$ ./go-gin-example …[GIN-debug] DELETE /api/v1/articles/:id –> github.com/EDDYCJY/go-gin-example/routers/api/v1.DeleteArticle (4 handlers)[GIN-debug] POST /api/v1/articles/poster/generate –> github.com/EDDYCJY/go-gin-example/routers/api/v1.GenerateArticlePoster (4 handlers)Actual pid is 14672重启 nginx$ nginx -tnginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is oknginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful$ nginx -s reload访问接口如此，就实现了一个简单的反向代理了，是不是很简单呢负载均衡负载均衡，英文名称为Load Balance（常称 LB），其意思就是分摊到多个操作单元上进行执行（来自百科）你能从运维口中经常听见，XXX 负载怎么突然那么高。 那么它到底是什么呢？其背后一般有多台 server，系统会根据配置的策略（例如 Nginx 有提供四种选择）来进行动态调整，尽可能的达到各节点均衡，从而提高系统整体的吞吐量和快速响应如何演示前提条件为多个后端服务，那么势必需要多个 go-gin-example，为了演示我们可以启动多个端口，达到模拟的效果 为了便于演示，分别在启动前将 conf/app.ini 的应用端口修改为 8001 和 8002（也可以做成传入参数的模式），达到启动 2 个监听 8001 和 8002 的后端服务配置 nginx.conf回到 nginx.conf 的老地方，增加负载均衡所需的配置。新增 upstream 节点，设置其对应的 2 个后端服务，最后修改了 proxy_pass 指向（格式为 http:// + upstream 的节点名称）worker_processes 1;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream api.blog.com { server 127.0.0.1:8001; server 127.0.0.1:8002; } server { listen 8081; server_name api.blog.com; location / { proxy_pass http://api.blog.com/; } }}重启 nginx$ nginx -tnginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is oknginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful$ nginx -s reload验证再重复访问 http://api.blog.com:8081/auth?username={USER_NAME}}&password={PASSWORD}，多访问几次便于查看效果目前 Nginx 没有进行特殊配置，那么它是轮询策略，而 go-gin-example 默认开着 debug 模式，看看请求 log 就明白了总结在本章节，希望您能够简单习得日常使用的 Web Server 背后都是一些什么逻辑，Nginx 是什么？反向代理？负载均衡？怎么简单部署，知道了吧。参考本系列示例代码go-gin-example ...

Kibana汉化使用中文界面实践一、背景笔者在上一篇文章使用Docker快速部署ELK分析Nginx日志实践当中有提到如何快速搭建ELK分析Nginx日志，但是这只是第一步，后面还有很多仪表盘需要配置，而对于大部分人来说，英文并不是那么好，但Kibana都是英文界面，这就阻碍了笔者熟悉Kibana的一些操作；所以笔者思考能不能将其汉化，在搜索引擎中找到了一些文章，发现汉化相对来说成本还算比较低，因此进行了一番实践，整个操作流程即便是将前人的汉化包拿过来使用，但使用的过程汉化包的作者并没有过多的讲解，本文主要是讲解如何使用汉化包以及操作过程的记录。笔者上一篇文章使用Docker快速部署ELK分析Nginx日志实践URL地址：https://segmentfault.com/a/11…二、操作概述汉化包下载运行环境安装汉化效果演示三、汉化包下载笔者所使用的汉化包项目名称为Kibana_Hanization,在Github上进行了开源，URL地址如下https://github.com/anbai-inc/Kibana_Hanization在上一篇文章当中笔者已经将/Users/song/dockerFile/挂载在容器的/data当中，因此可以直接在宿主机中通过git拉取汉化包，然后去容器里面运行它，参考命令如下cd /Users/song/dockerFile/ && git clone https://github.com/anbai-inc/Kibana_Hanization.git四、运行环境安装安装汉化包，需要完成三个步骤，首先需要有执行汉化包里面工具的Python2.7环境，然后需要找到Kibana的安装目录，最后才能执行安装，具体操作如下4.1 安装Python2.7笔者直接运行汉化包的时候发现此汉化工具依赖于Python2.7，而ELK中默认安装的是Python3，因此笔者需要先安装Python2.7的运行环境，操作如下首先需要拉取Python仓库地址apt update然后执行安装，参考命令如下apt install python2.74.2 查找安装位置安装好Python的运行环境之后，笔者还需要找到kibana的安装位置，参考命令如下所示find / -iname kibana命令执行后返回的结果/opt/logstash/x-pack/modules/azure/configuration/kibana/opt/logstash/x-pack/modules/arcsight/configuration/kibana/opt/logstash/modules/netflow/configuration/kibana/opt/logstash/modules/fb_apache/configuration/kibana/opt/kibana/opt/kibana/src/core_plugins/kibana/opt/kibana/node_modules/x-pack/plugins/ml/server/models/data_recognizer/modules/apache2/kibana/opt/kibana/node_modules/x-pack/plugins/ml/server/models/data_recognizer/modules/nginx/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/server/lib/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/server/lib/metrics/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/server/routes/api/v1/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/public/views/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/public/components/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/public/directives/kibana/opt/kibana/node_modules/@kbn/pm/src/utils/fixtures/kibana/opt/kibana/bin/kibana/etc/logrotate.d/kibana/etc/init.d/kibana根据返回结果和以往的经验，大致猜测出安装位置在/opt/kibana下，在得到安装目录之后，现在笔者需要进入此前在宿主机通过git下载的汉化包目录，因为运行elk容器的时候已经将宿主机目录挂载进去，因此容器中可以进入，参考吗命令如下cd /data/Kibana_Hanization4.2 汉化包安装执行汉化命令python2.7 main.py /opt/kibana/返回结果文件[/opt/kibana/optimize/bundles/kibana.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/commons.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/login.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/ml.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/monitoring.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/timelion.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/vendors.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/apm.bundle.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/ui_setting_defaults.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/translations/en.json]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/docker_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/elastic_cloud.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/on_prem_elastic_cloud.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/on_prem.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/common_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/kubernetes_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apache_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/redis_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apm/apm_server_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apm/apm_client_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/nginx_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/system_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/system_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apache_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/nginx_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/redis_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/mysql_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/mysql_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/common/tutorials/filebeat_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/common/tutorials/metricbeat_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/public/dashboard/index.js]已翻译。文件[/opt/kibana/src/core_plugins/timelion/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/line.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/area.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/heatmap.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/horizontal_bar.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/histogram.js]已翻译。文件[/opt/kibana/src/ui/public/chrome/directives/global_nav/global_nav.js]已翻译。恭喜，Kibana汉化完成！笔者执行这条命令时间大约在10秒钟左右。五、汉化效果演示经过上一步操作，已经完成了汉化包的安装，现在笔者进入Kibana的主页来验证汉化的效果，Kibana主页的URL地址如下http://localhost:5601/app/kibana#/home?_g=()但在实际汉化后发现并没有完全汉化,笔者所使用的ELK版本为6.4.0,效果如下图所示而汉化包中介绍的汉化效果效果却如下图所示笔者猜测可能是自己使用的ELK版本比较新，而汉化包还没用跟上节奏所导致，不过效果已经很棒了；笔者接着又打开了几个页面，发现汉化效果大都在80%左右，视图创建URL地址如下http://localhost:5601/app/kibana#/visualize/new?_g=()在浏览器中打开视图创建页面后，展现汉化如下图所示作者：汤青松微信：songboy8888日期：2018-08-31

一、背景笔者最近折腾docker服务比较多，这几天想把在内网中的服务搬到公网当中，但docker对内存要求较高，而云服务高内存的服务器又比较贵，家里虽然有一台旧笔记本内存还可以，但是没有公网IP地址，视乎还是没有办法，就在纠结的时候想起FRP这个内网穿透软件，重新回顾了一下搭建方法，发现搭建步骤较为简单，为了以后有所参考，所以把搭建步骤详细记录了下来。二、操作步骤配置服务端配置客户端检验与测试三、配置服务端FRP分为服务端与客户端，一个服务端可以对应多个客户端，笔者首先需要在服务器中下载并安装FRP3.1 文件选择frp是开源的一个内网穿透软件，github源码以及文档地址如下https://github.com/fatedier/frp在文档当中可以看到编译好的二进制文件，URL地址如下：https://github.com/fatedier/frp/releases在下载地址当中有多个版本，笔者需要选择自己所对应系统的版本，笔者服务器使用的是64位的Centos系统，客户端使用的是mac系统，因此需要下载frp_0.21.0_linux_amd64.tar.gz和frp_0.21.0_darwin_amd64.tar.gz两个压缩包，如下图所示3.2 下载与解压现在需要在服务器中下载对应版本，首先通过ssh登录服务器，参考命令如下ssh root@121.42.11.33登录服务器之后，笔者需要使用wget下载文件，参考命令如下wget https://github.com/fatedier/frp/releases/download/v0.21.0/frp_0.21.0_linux_amd64.tar.gz下载之后，需要解压刚才下载的压缩文件，参考命令如下tar -zxvf frp_0.21.0_linux_amd64.tar.gz命令返回结果如下frp_0.21.0_linux_amd64/frp_0.21.0_linux_amd64/frps_full.inifrp_0.21.0_linux_amd64/frps.inifrp_0.21.0_linux_amd64/frpcfrp_0.21.0_linux_amd64/frpc_full.inifrp_0.21.0_linux_amd64/frpsfrp_0.21.0_linux_amd64/LICENSEfrp_0.21.0_linux_amd64/frpc.ini解压之后并进入文件夹查看，参考命令如下cd frp_0.21.0_linux_amd64 && ll返回结果如下-rw-rw-r– 1 root root 12K Aug 12 12:38 LICENSE-rwxrwxr-x 1 root root 7.2M Aug 12 12:34 frpc-rw-rw-r– 1 root root 126 Aug 12 12:38 frpc.ini-rw-rw-r– 1 root root 5.6K Aug 12 12:38 frpc_full.ini-rwxrwxr-x 1 root root 8.6M Aug 12 12:34 frps-rw-rw-r– 1 root root 26 Aug 12 12:38 frps.ini-rw-rw-r– 1 root root 2.4K Aug 12 12:38 frps_full.ini3.3 修改配置在返回结果当中可以看到有多个文件，不过笔者实际上只需要关心frps和frps.ini就可以了查看配置文件参考命令如下cat frps.ini返回结果如下[common]bind_port = 7000在返回结果当中可以看到端口为7000，这个端口便是FRP与客户端通信的端口，因为笔者需要搭建Web服务，所以需要在配置文件当中加入http服务的监听端口，参考命令如下vim frps.ini修改配置文件，修改后的配置文件内容如下[common]bind_port = 7000vhost_http_port = 88883.4 服务启动修改完成之后，笔者便可启动FRPS服务，参考命令如下./frps -c frps.ini返回结果2018/08/29 23:43:30 [I] [service.go:130] frps tcp listen on 0.0.0.0:70002018/08/29 23:43:30 [I] [service.go:172] http service listen on 0.0.0.0:88882018/08/29 23:43:30 [I] [root.go:207] Start frps success四、配置客户端在配置服务端完成之后，笔者还需要在内网中配置客户端，这个客户端也就是Web服务器，具体操作如下4.1 下载与解压搭建FRP客户端，首先需要在客户端下载FRP压缩文件；笔者mac系统所下载文件及对应的参考命令如下wget https://github.com/fatedier/frp/releases/download/v0.21.0/frp_0.21.0_darwin_amd64.tar.gz下载之后同样需要解压文件，参考命令如下tar -zxvf frp_0.21.0_darwin_amd64.tar.gz命令执行之后返回结果如下x frp_0.21.0_darwin_amd64/x frp_0.21.0_darwin_amd64/frps_full.inix frp_0.21.0_darwin_amd64/frps.inix frp_0.21.0_darwin_amd64/frpcx frp_0.21.0_darwin_amd64/frpc_full.inix frp_0.21.0_darwin_amd64/frpsx frp_0.21.0_darwin_amd64/LICENSEx frp_0.21.0_darwin_amd64/frpc.ini进入解压的文件夹中并查看文件列表，参考命令如下cd frp_0.21.0_darwin_amd64 && ll执行后返回的信息如下total 35632-rw-r–r– 1 song staff 11K Aug 12 12:38 LICENSE-rwxr-xr-x 1 song staff 8.0M Aug 12 12:33 frpc-rw-r–r– 1 song staff 126B Aug 12 12:38 frpc.ini-rw-r–r– 1 song staff 5.6K Aug 12 12:38 frpc_full.ini-rwxr-xr-x 1 song staff 9.4M Aug 12 12:33 frps-rw-r–r– 1 song staff 26B Aug 12 12:38 frps.ini-rw-r–r– 1 song staff 2.3K Aug 12 12:38 frps_full.ini4.2 配置服务客户端所需注意的文件有两个，分别是frpc和frpc.ini,先来查看配置文件默认内容是什么，参考命令如下cat frpc.ini返回结果如下[common]server_addr = 127.0.0.1server_port = 7000[ssh]type = tcplocal_ip = 127.0.0.1local_port = 22remote_port = 6000在默认的客户端配置文件当中，配置了一个TCP映射，不过笔者需要搭建Web服务，因此还需要添加一个HTTP映射，并修改对应的服务端IP地址，参考命令如下vim fprc.ini编辑后的结果如下所示[common]server_addr = 121.42.11.33server_port = 7000[ssh]type = tcplocal_ip = 127.0.0.1local_port = 22remote_port = 5000[web]type = httplocal_port = 8080custom_domains = test.songboy.net4.3 启动服务修改客户端的配置文件完成之后，笔者需要让客户端的FRP来连接服务端的FRP服务，参考命令如下sudo ./frpc -c frpc.ini执行命令后返回结果如下所示2018/08/30 09:50:07 [I] [proxy_manager.go:300] proxy removed: []2018/08/30 09:50:07 [I] [proxy_manager.go:310] proxy added: [ssh web]2018/08/30 09:50:07 [I] [proxy_manager.go:333] visitor removed: []2018/08/30 09:50:07 [I] [proxy_manager.go:342] visitor added: []2018/08/30 09:50:07 [I] [control.go:246] [55b8b354889e6f44] login to server success, get run id [55b8b354889e6f44], server udp port [0]2018/08/30 09:50:07 [I] [control.go:169] [55b8b354889e6f44] [ssh] start proxy success2018/08/30 09:50:07 [I] [control.go:169] [55b8b354889e6f44] [web] start proxy success在返回结果当中，可以看到ssh服务代理成功，web服务也代理成功，说明笔者的配置无误五、检验与测试前面的操作已经成功的配置了内网穿透服务，现在笔者需要通过ssh登录和web服务来验证服务是否可用，操作步骤如下5.1 测试Web服务测试Web服务是否穿透可以通过访问外网地址，如果能打开内网中的Web服务便说明搭建成功，这里需要搭建一个虚拟主机，参展步骤如下5.1.2 添加虚拟主机要让用户能通过外网访问Web服务，首先需要配置一个域名让其解析到FRP服务器当中，这里为了验证方面，便使用hosts添加记录方式操作，参考命令如下sudo vim /etc/hosts在尾部添加一条host记录，参考内容如下121.42.11.33 test.songboy.net添加的内容当中，IP地址为外网用户能访问到的IP地址，也就是笔者开始搭建FRP服务器的IP地址接下来笔者还需要增加一个虚拟主机，所以需要修改nginx配置文件，在nginx配置文件中添加配置如下server {listen 8080;server_name test.songboy.net;root /Users/song/mycode/work/media-server-api/public;index index.html index.htm index.php;location / {try_files $uri $uri/ /index.php?$query_string;}location ~ .php$ {fastcgi_pass 127.0.0.1:9000;fastcgi_index index.php;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;include fastcgi_params;}}重启nginx ，参考命令如下sudo nginx -s reload5.1.3 访问网站通过浏览器访问，URL地址如下http://test.songboy.net:8888/访问结果如下图所示5.2 测试SSH服务验证SSH的方式是通过ssh连接外网地址，如果登陆到本地服务器便说明ssh服务搭建成功使用ssh登陆，参考命令如下ssh -p 5000 song@test.songboy.net查看当前文件夹，验证是否已经映射成功，参考命令如下ls -l返回结果如下total 0drwx——@ 4 song staff 136 7 19 18:37 Applicationsdrwx——@ 12 song staff 408 8 30 09:47 Desktopdrwx——@ 30 song staff 1020 8 6 08:58 Documentsdrwx——+ 120 song staff 4080 8 29 17:05 Downloadsdrwx——@ 65 song staff 2210 8 18 16:12 Librarydrwx——+ 5 song staff 170 8 17 15:19 Moviesdrwx——+ 5 song staff 170 7 26 11:45 Musicdrwx——+ 4 song staff 136 8 28 19:21 Picturesdrwxr-xr-x+ 4 song staff 136 7 19 16:33 Publicdrwxr-xr-x 8 song staff 272 8 24 14:26 configdrwxr-xr-x 22 song staff 748 8 14 11:00 datadrwxr-xr-x 7 song staff 238 8 24 19:31 dockerFiledrwxr-xr-x 12 song staff 408 8 30 09:28 filesdrwxr-xr-x 7 song staff 238 8 13 09:54 mycodedrwxrwxrwx 20 song staff 680 8 27 16:35 xhprof在返回结果当中，可以看到文件夹与客户端的文件夹一致，便说明ssh服务以及验证成功。作者：汤青松微信：songboy8888日期：2018-08-30 ...

社区内有人发起了一个讨论，关于JVM是否一定需要GC？他们认为应用程序的回收目标是构建一个仅用来处理内存分配，而不执行任何真正的内存回收操作的 GC。即仅当可用的 Java 堆耗尽的时候，才进行顺序的 JVM 停顿操作。首先需要理解为什么需要GC。随着应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。社区的需求是尽量减少对应用程序的正常执行干扰，这也是业界目标。Oracle在JDK7时发布G1 GC的目的是为了减少应用程序停顿发生的可能性，让我们通过本文来了解G1 GC所做的工作。JVM发展历史简介还记得机器猫吗？他和康夫有一张书桌，书桌的抽屉其实是一个时空穿梭通道，让我们操作机器猫的时空机器，回到1998年。那年的12月8日，第二代Java平台的企业版J2EE正式对外发布。为了配合企业级应用落地，1999年4月27日，Java程序的舞台—Java HotSpot Virtual Machine（以下简称HotSpot ）正式对外发布，并从这之后发布的JDK1.3版本开始，HotSpot成为Sun JDK的默认虚拟机。GC发展历史简介1999年随JDK1.3.1一起来的是串行方式的Serial GC ，它是第一款GC，并且这只是起点。此后，JDK1.4和J2SE1.3相继发布。2002年2月26日，J2SE1.4发布，Parallel GC 和Concurrent Mark Sweep （CMS）GC跟随JDK1.4.2一起发布，并且Parallel GC在JDK6之后成为HotSpot默认GC。HotSpot有这么多的垃圾回收器，那么如果有人问，Serial GC、Parallel GC、Concurrent Mark Sweep GC这三个GC有什么不同呢？请记住以下口令：如果你想要最小化地使用内存和并行开销，请选Serial GC；如果你想要最大化应用程序的吞吐量，请选Parallel GC；如果你想要最小化GC的中断或停顿时间，请选CMS GC。那么问题来了，既然我们已经有了上面三个强大的GC，为什么还要发布Garbage First（G1）GC？原因就在于应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。为什么名字叫做Garbage First（G1）呢？因为G1是一个并行回收器，它把堆内存分割为很多不相关的区间（Region），每个区间可以属于老年代或者年轻代，并且每个年龄代区间可以是物理上不连续的。老年代区间这个设计理念本身是为了服务于并行后台线程，这些线程的主要工作是寻找未被引用的对象。而这样就会产生一种现象，即某些区间的垃圾（未被引用对象）多于其他的区间。垃圾回收时实则都是需要停下应用程序的，不然就没有办法防治应用程序的干扰 ，然后G1 GC可以集中精力在垃圾最多的区间上，并且只会费一点点时间就可以清空这些区间里的垃圾，腾出完全空闲的区间。绕来绕去终于明白了，由于这种方式的侧重点在于处理垃圾最多的区间，所以我们给G1一个名字：垃圾优先（Garbage First）。G1 GC基本思想G1 GC是一个压缩收集器，它基于回收最大量的垃圾原理进行设计。G1 GC利用递增、并行、独占暂停这些属性，通过拷贝方式完成压缩目标。此外，它也借助并行、多阶段并行标记这些方式来帮助减少标记、重标记、清除暂停的停顿时间，让停顿时间最小化是它的设计目标之一。G1回收器是在JDK1.7中正式投入使用的全新的垃圾回收器，从长期目标来看，它是为了取代CMS 回收器。G1回收器拥有独特的垃圾回收策略，这和之前提到的回收器截然不同。从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区，但从堆的结构上看，它并不要求整个Eden区、年轻代或者老年代在物理上都是连续。综合来说，G1使用了全新的分区算法，其特点如下所示：并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力；并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况；分代GC：G1依然是一个分代收集器，但是和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代；空间整理：G1在回收过程中，会进行适当的对象移动，不像CMS只是简单地标记清理对象。在若干次GC后，CMS必须进行一次碎片整理。而G1不同，它每次回收都会有效地复制对象，减少空间碎片，进而提升内部循环速度。可预见性：由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。随着G1 GC的出现，GC从传统的连续堆内存布局设计，逐渐走向不连续内存块，这是通过引入Region概念实现，也就是说，由一堆不连续的Region组成了堆内存。其实也不能说是不连续的，只是它从传统的物理连续逐渐改变为逻辑上的连续，这是通过Region的动态分配方式实现的，我们可以把一个Region分配给Eden、Survivor、老年代、大对象区间、空闲区间等的任意一个，而不是固定它的作用，因为越是固定，越是呆板。G1 GC垃圾回收机制通过市场的力量，不断淘汰旧的行业，把有限的资源让给那些竞争力更强、利润率更高的企业。类似地，硅谷也在不断淘汰过时的人员，从全世界吸收新鲜血液。经过半个多世纪的发展，在硅谷地区便形成只有卓越才能生存的文化。本着这样的理念，GC承担了淘汰垃圾、保存优良资产的任务。G1 GC在回收暂停阶段会回收最大量的堆内区间（Region），这是它的设计目标，通过回收区间达到回收垃圾的目的。这里只有一个例外情况，这个例外发生在并行标记阶段的清除（Cleanup）步骤，如果G1 GC在清除步骤发现所有的区间都是由可回收垃圾组成的，那么它会立即回收这些区间，并且将这些区间插入到一个基于LinkedList实现的空闲区间队列里，以待后用。因此，释放这些区间并不需要等待下一个垃圾回收中断，它是实时执行的，即清除阶段起到了最后一道把控作用。这是G1 GC和之前的几代GC的一大差别。G1 GC的垃圾回收循环由三个主要类型组成：年轻代循环多步骤并行标记循环混合收集循环Full GC在年轻代回收期，G1 GC暂停应用程序线程，然后从年轻代区间移动存活对象到Survivor区间或者老年区间，也有可能是两个区间都会涉及。对于一个混合回收期，G1 GC从老年区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。G1的区间设计灵感为了加快GC的回收速度，HotSpot的历代GC都有自己的不同的设计方案，区间概念在软件设计、架构领域并不是一个新名词，关系型数据库、列式数据库最先使用这个概念提升数据存、取速度，软件架构设计时也广泛使用这样的分区概念加快数据交换、计算。为什么会有区间这个设计想法？大家一定看过电视剧《大宅门》吧？大宅门所描述的北京知名医术世家白家是这本电视剧的主角。白家有三兄弟，没有分家之前，由老爷子一手掌管全家，老爷子看似是个精明人，实质是个糊涂的人，否则也不会弄得后来白家家破人散。白家的三兄弟在没有分家之前，老大一家很老实，老二很懦弱，性格像女人，虽然肚子里明白道理，但是不敢出来做主。老三年轻时混蛋一个，每次出外采购药材都要私吞家里的银两，造成账目混乱。老大为了家庭和睦，一直在私下倒贴银两，让老爷子能够看到一本正常的账目。这样的一家子聚在一起，迟早家庭内部会出现问题，倒不如分家，你也不用算计家里的钱了，分给你，分给你的钱有本事守住，没本事就一直拮据下去吧。这就是最原始的分区（Region）概念。我们回到技术，看看HBase的RegionServer设计方式。在HBase内部，所有的用户数据以及元数据的请求，在经过Region的定位，最终会落在RegionServer上，并由RegionServer实现数据的读写操作。RegionServer是HBase集群运行在每个工作节点上的服务。它是整个HBase系统的关键所在，一方面它维护了Region的状态，提供了对于Region的管理和服务；另一方面，它与Master交互，上传Region的负载信息上传，参与Master的分布式协调管理。HRegionServer与HMaster以及Client之间采用RPC协议进行通信。HRegionServer向HMaster定期汇报节点的负载状况，包括RS内存使用状态、在线状态的Region等信息。在该过程中HRegionServer扮演了RPC客户端的角色，而HMaster扮演了RPC服务器端的角色。HRegionServer内置的RpcServer实现了数据更新、读取、删除的操作，以及Region涉及到Flush、Compaction、Open、Close、Load文件等功能性操作。Region是HBase数据存储和管理的基本单位。HBase使用RowKey将表水平切割成多个HRegion，从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey（第一个HRegion的StartKey为空，最后一个HRegion的EndKey为空），由于RowKey是排序的，因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。HRegion由HMaster分配到相应的HRegionServer中，然后由HRegionServer负责HRegion的启动和管理，和Client的通信，负责数据的读(使用HDFS)。每个HRegionServer可以同时管理1000个左右的HRegion。再来看看软件系统架构方面的分区设计。以任务调度为例，假设我们有一个中心调度服务，那么当数据量不断增多，这个中心调度服务一定会遇到性能瓶颈，因为所有的请求都会最终指向它。为了解决这个性能瓶颈，我们可以将任务调度拆分为多个服务，即这多个服务都可以处理任务调度工作，那么问题来了，每个任务调度服务处理的源数据是否需要完全一致？根据华为公司发布的专利发明，显示他们对于每一个任务调度服务有数据来源区分的操作，即按照任务调度数量对源数据进行划分，比如3个任务调度服务，那么源数据按照行号对3取余的方式划分，如果运行了一段时间之后，任务调度服务出现了数量上的增减，那么这个取余划分需要重新进行，要按照那个时候的任务调度数量重新划分区间。回到G1。在G1中，堆被平均分成若干个大小相等的区域（Region）。每个Region都有一个关联的Remembered Set（简称RS），RS的数据结构是Hash表，里面的数据是Card Table （堆中每512byte映射在card table 1byte）。简单的说RS里面存在的是Region中存活对象的指针。当Region中数据发生变化时，首先反映到Card Table中的一个或多个Card上，RS通过扫描内部的Card Table得知Region中内存使用情况和存活对象。在使用Region过程中，如果Region被填满了，分配内存的线程会重新选择一个新的Region，空闲Region被组织到一个基于链表的数据结构（LinkedList）里面，这样可以快速找到新的Region。总结没有GC机制的JVM是不能想象的，我们只能通过不断优化它的使用、不断调整自己的应用程序，避免出现大量垃圾，而不是一味认为GC造成了应用程序问题。在此我向大家推荐一个架构学习交流群。交流学习群号：478030634 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多大家觉得文章对你还是有一点点帮助的，大家可以点击下方二维码进行关注。 《乐趣区》 公众号聊的不仅仅是Java技术知识，还有面试等干货，后期还有大量架构干货。大家一起关注吧！关注烂猪皮，你会了解的更多…………..