Cms

在日常生活和工作中，一个高效且实用的知识库已成为咱们的得力助手。但如何确保它不仅仅是信息的堆砌，真正为用户发明价值与效益？接下来，咱们将深入探讨这一问题，并借助HelpLook知识库的数据分析性能，带您全面理解如何优化知识库，以更精准地服务于用户。  | 为什么知识库须要接入剖析性能？ 在谋求极致用户体验的时代，知识库成为连贯企业与用户的桥梁。通过深度开掘和剖析数据，咱们能更精准地了解用户需要，优化内容和服务，从而为用户提供贴心体验。  1. 加强客户反对成果利用知识库剖析性能，可精准推送用户内容，升高待处理问题量。钻研显示，91%的用户冀望能在知识库中自助找到答案。有价值的内容能缩小用户懊恼，晋升问题解决效率。通过测试不同模式的帮忙文档（文本/视频格式等），可找到最适宜用户的出现形式。  2. 吸引潜在用户深度剖析数据报告不仅能助力知识库优化，还能吸引更多潜在用户。通过知识库吸引SEO流量，生成销售线索。联合知识库解决方案的剖析性能（如HelpLook的数据分析）与Google Analytics报告，发现哪些关键词和页面最受搜索引擎青眼，更直观地理解用户需要。  3. 晋升产品接受度在产品试用阶段，用户常对某些性能感到困惑，从而转向企业搭建的产品帮忙核心求助。若信息难寻或缺失，易致用户散失。侥幸的是，知识库的剖析性能能助你辨认并填补空白，升高流失率。 | 如何通过HelpLook追踪知识库数据？要追踪知识库的数据，个别须要集成谷歌、百度等数据分析平台，实现实时的数据分析。然而，HelpLook知识库自带的数据分析性能即可满足你的需要。轻松实现实时追踪，助你洞悉知识库体现和用户行为。  1. 跟踪知识库文章体现通过每日或每月的站点数据追踪，能够轻松把握站点浏览数、拜访用户数以及文章反馈数等多项要害指标。这些数据不仅能帮忙咱们深刻理解用户的浏览习惯，还能为优化内容策略提供无力反对。    2. 剖析客户搜寻行为用户通过哪些形式找到你的知识库？他们通常搜寻什么内容？这些数据藏着大机密。若用户常搜寻找到你的知识库文章，意味着你的内容品质高且搜索引擎优化（SEO）做得很好。 剖析这些数据，理解客户实在需要，优化内容，能力一直晋升用户体验。您能够轻松追踪知识库的流量起源，依据以下方面剖析流量：  ① 流量起源HelpLook的访客性能为你提供了具体的用户行为数据，包含用户起源网站、拜访日期和门路占比等。通过这些数据，能够剖析出用户的拜访习惯。例如您能够通过HelpLook数据分析工具，查看流量起源（bing.com或baidu.com等）。   ② 搜索词通过查看搜索词，轻松查看所有用户的搜索词，还能依据他们搜寻的次数来排序。这样就能一眼看出大家最常搜寻的主题、关键词和热门问题，洞察他们的需要和关注点。    ③ 搜寻与点击的文章用HelpLook搜寻，不仅疾速找答案，还能发现知识库的有余。看看用户搜什么但没找到答案，就晓得哪里须要补充。及时欠缺，确保常识全面精确，让用户总能找到想要的答案。   ④ 数据周报你还能够通过拜访HelpLook 后盾中的”数据周报“获取每周报告，深刻理解用户如何与你的知识库互动，监控访问者数量。要找到这些报告，能够转到“设置”→“站点设置”→“告诉”→“数据周报”，设置好后，每周精彩数据将直送你的邮箱。   HelpLook作为一款全方位的知识库助手，不仅提供了便捷的搜寻和浏览性能，更通过深刻的数据分析，帮忙你全方位理解用户需要和行为。在这个信息爆炸的时代，把握用户需要和行为的企业或集体，无疑将更具竞争力。  无妨试试HelpLook! 感兴趣能够通过邀请码【LookLook111】收费应用HelpLook！让它成为你获取常识和洞察用户需要的得力助手，帮忙你更好地满足用户需要，晋升企业服务质量和用户体验。

简略来说几个步骤 读取要加载的文件内容执行文件内容给执行后的后果包一层module外壳并返回一个导出文件module.js module.exports = function () { return "hello world";};引入这个导出文件index.js const hello = my_Require("./module.js");console.log("hello~", hello());my_Require实现 const { readFileSync } = require("fs");const path = require("path");const { Script } = require("vm");function my_Require(filename) { // read file const fileContent = readFileSync(path.resolve(__dirname, filename), "utf-8"); // fileContent蕴含了module.exports,上面套上这层壳 const wrapperFileContent = `(function(require,module,exports){ ${fileContent}})`; // 运行字符串 const scripts = new Script(wrapperFileContent, { filename: "index.js", }); const module = { exports: {}, }; const res = scripts.runInThisContext(); res(my_Require, module, module.exports); return module.exports;}global.my_Require = my_Require;my_Require("./index.js");运行requier.js文件打印出hello~ hello world ...

新品业务线上化规则化的推动过程中，须要新增首发素材审核 CMS 并内嵌于营销中心，提供业务经营更加便捷的打分、评审的体验。在技术选型的过程中，新品团队理解到水滴低代码平台具备可视化搭建 CMS 的能力，内置了丰盛能力，可能高效、疾速地搭建 CMS，例如表单表格、权限管控、微前端等。与业务诉求的产品状态符合度高、设计格调统一并且默认反对微前端，在运维部署上简直能够做到零老本，十分不便就能将产物嵌在营销中心内。在技术调研并比照全副开发所须要的40+人日后，团队抉择了更高效的水滴低代码作为 CMS 的实现形式，并在 6 人日内实现了整个共建、搭建流程。本文将营销中心-新品首发素材审核 CMS （下文简称新品CMS） 的搭建梳理作为最佳实际，从 0 开始介绍如何应用水滴低代码平台。 01水滴—CMS疾速解决方案 水滴具备面向编程、低代码两个方向的劣势，两者相辅相成，向开发者提供了涵盖中后盾管理系统各角度的解决方案，次要亮点性能包含： 水滴性能亮点 上面将率领大家以开发者的视角，以营销中心新品 CMS 的搭建，作为最佳实际，一步步从需要评审，到组件开发，再到页面搭建，最终将 CMS 公布上线。 新品 CMS 最终成果 02新品CMS需要剖析 在梳理需要后，对于营销中心新品 CMS 利用，剖析出以下特点： 业务简单：各个模块间的关联性强、数据简单程度较高交互场景多：页面间有较多的跳转、数据传递的需要，模块之间有较多的交互需要高 UI 还原度：须要合乎营销中心设计语言，保持一致设计格调微前端组合：新品 CMS 并非独立应用，而是嵌入在营销中心内作为子利用应用开发周期短：3 个页面（ 6 个表单、4 个表格），从开发到提测，仅有 6 天的工夫 除了特点剖析，作者还梳理页面及组件，因为业务和交互的定制场景，仍有 4 个业务组件须要定制开发，好在水滴具备共建能力，开发者可定制业务组件集并导入零碎。 需要梳理 03组件共建开发 需要梳理后，接下来就是定制业务组件的流程。开发者能够在下载自定义组件模版库后，进行相干定制开发。模板内蕴含了组件开发的代码模板、罕用依赖、调试工具以及命令，开发实现当前可通过命令公布至 jnpm 。这样，就能够在水滴工作台的插件治理装置对应的组件集，装置实现当前即可在搭建页应用了。 定制组件开发流程 1、本地开发时可一边 coding ，一边进行表单、表格组件界面调试。 2、开发实现的定制组件集，胜利公布至 jnpm 仓库当前，即可在水滴工作台进行装置应用。 3、装置后的组件即可在搭建页面中进行拖拽应用。 至此，页面中须要的组件就全副开发实现，接下来将进入页面搭建环节吧~ 04页面可视化搭建 页面搭建环节就非常的简略了，水滴提供了表单表格设计器，只须要拖拖拽拽，就能将组件的布局和款式调整为 UI 设计稿中的样子。 为了缩小用户在调整布局和批改款式上的操作次数，水滴团队联结根底业务体验部 UI 设计团队制订了中后盾视觉规范，并落地到低代码平台中，使得一次拖拽即可达到现实中的款式。 水滴表单设计器 ...

前 CMS 时代90年代初期，互联网上的内容大多都由手工制作的动态页面组成的，这些网页由简略的 HTML 文件组成，文件又经 FTP 程序复制到 Web 服务器的目录中。 随后产生了一些列技术创新，使网络内容能以更丰盛的视觉效果展现，同时服务端内嵌（Server Side Includes）技术让网站的某些局部（如菜单和页脚）与次要内容离开，1996 年 IE 浏览器成为第一个反对 CSS 的浏览器。 以传统手工编辑上传文件的形式保护网站内容的形式开始难以满足人们的需要。于是诞生了 CMS。 CMS 的衰亡从 1995 年到 2000 年，服务端脚本风行一时，许多组织和公司应用 PHP、ASP 等技术开始创立定制化的 CMS，该期间的 CMS 特点是只实用于其组织的特定需要。 1990 年代中后期，一些公司预见到通用 CMS 的市场。1995 年 FileNet 推出了一套残缺的集成文档治理套件，被认为是第一个真正的内容管理系统。该期间的企业 CMS 还包含：StoryBuilder、Interwoven、Documentum、FatWire、FutureTense 和 Inso 到 2000 年代初，Ajax 技术衰亡，容许通过规范的 HTTP 申请办法动静更新内容，使网页具备了更强的交互性，开启了所谓的 Web2.0 时代。与此同时，开源内容管理系统和框架开始呈现，例如用 PHP 编程语言编写的过后风行的 Zend 框架。OpenCMS、WordPress 等。此时的 CMS 的外围变成了为不同的用户角色提供交付内容的能力。 挪动互联网时代2007 年 iPhone 和 2008 年 Android 智能手机问世，开启了挪动互联网时代。2014 年美国挪动设施的使用量超过了桌面使用量。挪动设施的遍及，使同一份网络内容须要反对在多种设施上拜访，而传统面向桌面端的 CMS 无奈提供多设施反对。通常须要针对移动用户提供精简版本的网站，而新型网络设备如智能手表、游戏机和语音助手的呈现加剧了传统 CMS 的内容交付问题。为了能真正的全渠道交付内容，人们须要更好的解决方案。 ...

筹备工具 宝塔面板 下载源码 Gitee地址：https://gitee.com/qq386654667... 创立网站 上传源码 将代码解压后上传到网站目录 网站配置 伪动态反对 设置运行目录 开始装置 拜访：http://域名/install 一、装置欢送界面 二、环境检测 三、权限检测 四、配置环境（倡议抉择表单配置） 根底信息 配置数据库（填写本人的数据库信息） 拓展驱动（如无特殊要求，临时默认即可） 装置实现 后盾拜访地址：/system/login 账号/明码：admin/admin

原文 内容管理系统，通常缩写为 CMS，是一种无需业余技术常识即可帮忙用户创立、治理和批改网站内容的软件。 用更简略的语言来说，内容管理系统是一种工具，能够帮忙您构建网站，而无需从头开始编写所有代码（甚至基本不晓得如何编码）。 内容管理系统不是构建您本人的用于创立网页、存储图像和其余性能的零碎，而是为您解决所有根本的基础设施内容，以便您能够专一于网站的更多面向前的局部。 除了网站，您还能够找到用于其余性能的内容管理系统，例如文档治理。 How Does a Content Management System Work?为了让您理解内容管理系统的工作原理，咱们将对 WordPress 界面进行一次旋风之旅（WordPress 是内容管理系统的一个很好的例子）。 让咱们从创立一个内容开始。 如果没有内容管理系统，您须要编写一个动态 HTML 文件并将其上传到您的服务器（听起来很简单，对吧？）。 应用像 WordPress 这样的内容管理系统，您能够在一个看起来很像 Microsoft Word 的界面中编写您的内容： 这要简略得多，对吧？ 同样，要上传和治理媒体（如图像），您只需浏览媒体库，而无需间接与您的 Web 服务器进行理论交互： 不过，内容管理系统不仅仅是一个后端治理界面。 它还能够让您创立的所有内容齐全依照您的志愿显示给访问者。 What Makes up a Content Management System?在技术层面上，内容管理系统由两个外围局部组成： 内容管理应用程序 (CMA) – 这是容许您在网站上理论增加和治理内容的局部（如您在下面看到的）。内容交付应用程序 (CDA) – 这是后盾的幕后流程，用于获取您在 CMA 中输出的内容、正确存储内容并使其对访问者可见。这两个零碎一起使保护您的网站变得容易。 What Are Examples of Popular Content Management Systems?咱们在上面向您展现的 WordPress 是风行内容管理系统的最佳示例。 尽管必定存在其余内容管理系统，但 WordPress 在具备已知内容管理系统的网站上放弃超过 40.0% 的市场份额。 请留神，当咱们提到“WordPress”时，咱们并不是在议论 WordPress.com。 相同，咱们专一于 WordPress.org，这是存储理论开源 WordPress 内容管理系统的网站。 ...

关于SDCMSSDCMS（网站信息管理系统）是在Php+Mysql架构环境下开发的开源产品。SDCMS以信息为主题，通过以文字和图片标题为起点，以无限栏目分类为支撑，配合多项插件的灵活使用，以达到信息门户的远景！SDCMS设计了全新的模板引擎，用户可以通过标签的自由组合，实现更丰富多彩的页面效果。 安装SDCMS首先，我们需要安装URLOS： curl -LO www.urlos.com/siu && sh siuURLOS面板安装完成之后，登录面板，在应用市场中搜素“SDCMS”，点击安装按钮： 在基本信息项目中填写服务名称、运行节点、端口号： 在网站项目中填写域名： 在数据库项目中选择数据库，设置数据库密码： 完成以上步骤后，点击提交，等待应用自动部署完成后，在浏览器中输入域名访问页面，如果页面能正常访问，则SDCMS部署成功。 本文我们介绍了如何使用URLOS快速创建SDCMS，对URLOS感兴趣的小伙伴不妨体验一下。

引子带着问题去学习一个东西，才会有目标感，我先把一直以来自己对CMS的一些疑惑罗列了下，希望这篇学习笔记能解决掉这些疑惑，希望也能对你有所帮助。CMS出现的初衷、背景和目的？CMS的适用场景？CMS的trade-off是什么?优势、劣势和代价CMS会回收哪个区域的对象？CMS的GC Roots包括那些对象？CMS的过程？CMS和Full gc是不是一回事？CMS何时触发？CMS的日志如何分析？CMS的调优如何做？CMS扫描那些对象？CMS和CMS collector的区别？CMS的推荐参数设置？为什么ParNew可以和CMS配合使用，而Parallel Scanvenge不可以？一、基础知识CMS收集器：Mostly-Concurrent收集器，也称并发标记清除收集器（Concurrent Mark-Sweep GC，CMS收集器），它管理新生代的方式与Parallel收集器和Serial收集器相同，而在老年代则是尽可能得并发执行，每个垃圾收集器周期只有2次短停顿。我之前对CMS的理解，以为它是针对老年代的收集器。今天查阅了《Java性能优化权威指南》和《Java性能权威指南》两本书，确认之前的理解是错误的。CMS的初衷和目的：为了消除Throught收集器和Serial收集器在Full GC周期中的长时间停顿。CMS的适用场景：如果你的应用需要更快的响应，不希望有长时间的停顿，同时你的CPU资源也比较丰富，就适合适用CMS收集器。二、CMS的过程CMS的正常过程这里我们首先看下CMS并发收集周期正常完成的几个状态。（STW）初始标记：这个阶段是标记从GcRoots直接可达的老年代对象、新生代引用的老年代对象，就是下图中灰色的点。这个过程是单线程的（JDK7之前单线程，JDK8之后并行，可以通过参数CMSParallelInitialMarkEnabled调整）。并发标记：由上一个阶段标记过的对象，开始tracing过程，标记所有可达的对象，这个阶段垃圾回收线程和应用线程同时运行，如上图中的灰色的点。在并发标记过程中，应用线程还在跑，因此会导致有些对象会从新生代晋升到老年代、有些老年代的对象引用会被改变、有些对象会直接分配到老年代，这些受到影响的老年代对象所在的card会被标记为dirty，用于重新标记阶段扫描。这个阶段过程中，老年代对象的card被标记为dirty的可能原因，就是下图中绿色的线：预清理：预清理，也是用于标记老年代存活的对象，目的是为了让重新标记阶段的STW尽可能短。这个阶段的目标是在并发标记阶段被应用线程影响到的老年代对象，包括：（1）老年代中card为dirty的对象；（2）幸存区(from和to)中引用的老年代对象。因此，这个阶段也需要扫描新生代+老年代。【PS：会不会扫描Eden区的对象，我看源代码猜测是没有，还需要继续求证】可中断的预清理：这个阶段的目标跟“预清理”阶段相同，也是为了减轻重新标记阶段的工作量。可中断预清理的价值：在进入重新标记阶段之前尽量等到一个Minor GC，尽量缩短重新标记阶段的停顿时间。另外可中断预清理会在Eden达到50%的时候开始，这时候离下一次minor gc还有半程的时间，这个还有另一个意义，即避免短时间内连着的两个停顿，如下图资料所示：在预清理步骤后，如果满足下面两个条件，就不会开启可中断的预清理，直接进入重新标记阶段：Eden的使用空间大于“CMSScheduleRemarkEdenSizeThreshold”，这个参数的默认值是2M；Eden的使用率大于等于“CMSScheduleRemarkEdenPenetration”，这个参数的默认值是50%。如果不满足上面两个条件，则进入可中断的预清理，可中断预清理可能会执行多次，那么退出这个阶段的出口有两个（源码参见下图）：* 设置了CMSMaxAbortablePrecleanLoops，并且执行的次数超过了这个值，这个参数的默认值是0；* CMSMaxAbortablePrecleanTime，执行可中断预清理的时间超过了这个值，这个参数的默认值是5000毫秒。 如果是因为这个原因退出，gc日志打印如下：有可能可中断预清理过程中一直没等到Minor gc，这时候进入重新标记阶段的话，新生代还有很多活着的对象，就回导致STW变长，因此CMS还提供了CMSScavengeBeforeRemark参数，可以在进入重新标记之前强制进行依次Minor gc。（STW）重新标记：重新扫描堆中的对象，进行可达性分析,标记活着的对象。这个阶段扫描的目标是：新生代的对象 + Gc Roots + 前面被标记为dirty的card对应的老年代对象。如果预清理的工作没做好，这一步扫描新生代的时候就会花很多时间，导致这个阶段的停顿时间过长。这个过程是多线程的。并发清除：用户线程被重新激活，同时将那些未被标记为存活的对象标记为不可达；并发重置：CMS内部重置回收器状态，准备进入下一个并发回收周期。CMS的异常情况上面描述的是CMS的并发周期正常完成的情况，但是还有几种CMS并发周期失败的情况：并发模式失败（Concurrent mode failure）：CMS的目标就是在回收老年代对象的时候不要停止全部应用线程，在并发周期执行期间，用户的线程依然在运行，如果这时候如果应用线程向老年代请求分配的空间超过预留的空间（担保失败），就回触发concurrent mode failure，然后CMS的并发周期就会被一次Full GC代替——停止全部应用进行垃圾收集，并进行空间压缩。如果我们设置了UseCMSInitiatingOccupancyOnly和CMSInitiatingOccupancyFraction参数，其中CMSInitiatingOccupancyFraction的值是70，那预留空间就是老年代的30%。晋升失败：新生代做minor gc的时候，需要CMS的担保机制确认老年代是否有足够的空间容纳要晋升的对象，担保机制发现不够，则报concurrent mode failure，如果担保机制判断是够的，但是实际上由于碎片问题导致无法分配，就会报晋升失败。永久代空间（或Java8的元空间）耗尽，默认情况下,CMS不会对永久代进行收集，一旦永久代空间耗尽，就回触发Full GC。三、CMS的调优针对停顿时间过长的调优首先需要判断是哪个阶段的停顿导致的，然后再针对具体的原因进行调优。使用CMS收集器的JVM可能引发停顿的情况有：（1）Minor gc的停顿；（2）并发周期里初始标记的停顿；（3）并发周期里重新标记的停顿；（4）Serial-Old收集老年代的停顿；（5）Full GC的停顿。其中并发模式失败会导致第（4）种情况，晋升失败和永久代空间耗尽会导致第（5）种情况。针对并发模式失败的调优想办法增大老年代的空间，增加整个堆的大小，或者减少年轻代的大小以更高的频率执行后台的回收线程，即提高CMS并发周期发生的频率。设置UseCMSInitiatingOccupancyOnly和CMSInitiatingOccupancyFraction参数，调低CMSInitiatingOccupancyFraction的值，但是也不能调得太低，太低了会导致过多的无效的并发周期，会导致消耗CPU时间和更多的无效的停顿。通常来讲，这个过程需要几个迭代，但是还是有一定的套路，参见《Java性能权威指南》中给出的建议，摘抄如下：> 对特定的应用程序，该标志的更优值可以根据 GC 日志中 CMS 周期首次启动失败时的值得到。具体方法是，在垃圾回收日志中寻找并发模式失效，找到后再反向查找 CMS 周期最近的启动记录，然后根据日志来计算这时候的老年代空间占用值，然后设置一个比该值更小的值。增多回收线程的个数CMS默认的垃圾收集线程数是*（CPU个数 + 3）/4*，这个公式的含义是：当CPU个数大于4个的时候，垃圾回收后台线程至少占用25%的CPU资源。举个例子：如果CPU核数是1-4个，那么会有1个CPU用于垃圾收集，如果CPU核数是5-8个，那么久会有2个CPU用于垃圾收集。针对永久代的调优如果永久代需要垃圾回收（或元空间扩容），就会触发Full GC。默认情况下，CMS不会处理永久代中的垃圾，可以通过开启CMSPermGenSweepingEnabled配置来开启永久代中的垃圾回收，开启后会有一组后台线程针对永久代做收集，需要注意的是，触发永久代进行垃圾收集的指标跟触发老年代进行垃圾收集的指标是独立的，老年代的阈值可以通过CMSInitiatingPermOccupancyFraction参数设置，这个参数的默认值是80%。开启对永久代的垃圾收集只是其中的一步，还需要开启另一个参数——CMSClassUnloadingEnabled，使得在垃圾收集的时候可以卸载不用的类。四、CMS的trade-off是什么？优势低延迟的收集器：几乎没有长时间的停顿，应用程序只在Minor gc以及后台线程扫描老年代的时候发生极其短暂的停顿。劣势更高的CPU使用：必须有足够的CPU资源用于运行后台的垃圾收集线程，在应用程序线程运行的同时扫描堆的使用情况。【PS：现在服务器的CPU资源基本不是问题，这个点可以忽略】CMS收集器对老年代收集的时候，不再进行任何压缩和整理的工作，意味着老年代随着应用的运行会变得碎片化；碎片过多会影响大对象的分配，虽然老年代还有很大的剩余空间，但是没有连续的空间来分配大对象，这时候就会触发Full GC。CMS提供了两个参数来解决这个问题：（1）UseCMSCompactAtFullCollection，在要进行Full GC的时候进行内存碎片整理；（2）CMSFullGCsBeforeCompaction，每隔多少次不压缩的Full GC后，执行一次带压缩的Full GC。会出现浮动垃圾；在并发清理阶段，用户线程仍然在运行，必须预留出空间给用户线程使用，因此CMS比其他回收器需要更大的堆空间。五、几个问题的解答为什么ParNew可以和CMS配合使用，而Parallel Scanvenge不可以？答：这个跟Hotspot VM的历史有关，Parallel Scanvenge是不在“分代框架”下开发的，而ParNew、CMS都是在分代框架下开发的。CMS中minor gc和major gc是顺序发生的吗？答：不是的，可以交叉发生，即在并发周期执行过程中，是可以发生Minor gc的，这个找个gc日志就可以观察到。CMS的并发收集周期合适触发？由下图可以看出，CMS 并发周期触发的条件有两个：阈值检查机制：老年代的使用空间达到某个阈值，JVM的默认值是92%（jdk1.5之前是68%，jdk1.6之后是92%），或者可以通过CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly两个参数来设置；这个参数的设置需要看应用场景，设置得太小，会导致CMS频繁发生，设置得太大，会导致过多的并发模式失败。例如动态检查机制：JVM会根据最近的回收历史，估算下一次老年代被耗尽的时间，快到这个时间的时候就启动一个并发周期。设置UseCMSInitiatingOccupancyOnly这个参数可以将这个特性关闭。CMS的并发收集周期会扫描哪些对象？会回收哪些对象？答：CMS的并发周期只会回收老年代的对象，但是在标记老年代的存活对象时，可能有些对象会被年轻代的对象引用，因此需要扫描整个堆的对象。CMS的gc roots包括哪些对象？答：首先，在JVM垃圾收集中Gc Roots的概念如何理解(参见R大对GC roots的概念的解释)；第二，CMS的并发收集周期中，如何判断老年代的对象是活着？我们前面提到了，在CMS的并发周期中，仅仅扫描Gc Roots直达的对象会有遗漏，还需要扫描新生代的对象。如下图中的蓝色字体所示，CMS中的年轻代和老年代是分别收集的，因此在判断年轻代的对象存活的时候，需要把老年代当作自己的GcRoots，这时候并不需要扫描老年代的全部对象，而是使用了card table数据结构，如果一个老年代对象引用了年轻代的对象，则card中的值会被设置为特殊的数值；反过来判断老年代对象存活的时候，也需要把年轻代当作自己的Gc Roots，这个过程我们在第三节已经论述过了。如果我的应用决定使用CMS收集器，推荐的JVM参数是什么？我自己的应用使用的参数如下，是根据PerfMa的xxfox生成的，大家也可以使用这个产品调优自己的JVM参数：-Xmx4096M -Xms4096M -Xmn1536M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses -XX:+CMSClassUnloadingEnabled -XX:+ParallelRefProcEnabled -XX:+CMSScavengeBeforeRemark -XX:ErrorFile=/home/admin/logs/xelephant/hs_err_pid%p.log -Xloggc:/home/admin/logs/xelephant/gc.log -XX:HeapDumpPath=/home/admin/logs/xelephant -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryErrorCMS相关的参数总结（需要注意的是，这里我没有考虑太多JDK版本的问题，JDK1.7和JDK1.8这些参数的配置，有些默认值可能不一样，具体使用的时候还需要根据具体的版本来确认怎么设置）| 编号 | 参数名称 | 解释 || — | — | — || 1 | UseConcMarkSweepGC | 启用CMS收集器 || 2 | UseCMSInitiatingOccupancyOnly | 关闭CMS的动态检查机制，只通过预设的阈值来判断是否启动并发收集周期 || 3 | CMSInitiatingOccupancyFraction | 老年代空间占用到多少的时候启动并发收集周期，跟UseCMSInitiatingOccupancyOnly一起使用 || 4 | ExplicitGCInvokesConcurrentAndUnloadsClasses | 将System.gc()触发的Full GC转换为一次CMS并发收集，并且在这个收集周期中卸载 Perm（Metaspace）区域中不需要的类 || 5 | CMSClassUnloadingEnabled | 在CMS收集周期中，是否卸载类 || 6 | ParallelRefProcEnabled | 是否开启并发引用处理 || 7 | CMSScavengeBeforeRemark | 如果开启这个参数，会在进入重新标记阶段之前强制触发一次minor gc |参考资料从实际案例聊聊Java应用的GC优化理解CMS垃圾回收日志图解CMS垃圾回收机制，你值得拥有为什么CMS虽然是老年代的gc，但仍要扫描新生代的?R大对GC roots的概念的解释Introduce to CMS Collector《深入理解Java虚拟机》《Java性能权威指南》Oracle的GC调优手册what-is-the-threshold-for-cms-old-gc-to-be-triggeredFrequently Asked Questions about Garbage Collection in the Hotspot Java VirtualMachineJava SE HotSpot at a Glancexxfox：PerfMa的参数调优神器详解CMS垃圾回收机制ParNew和PSYoungGen和DefNew是一个东西么？Java SE的内存管理白皮书Garbage Collection in Elasticsearch and the G1GCA Heap of Trouble毕玄的文章：为什么不建议JVM源码分析之SystemGC完全解读读者讨论关于CMS收集器的回收范围，下面这张图是有误导的，从官方文档上看来，CMS收集器包括年轻代和老年代的收集，只不过对年轻代的收集的策略和ParNew相同，这个可以从参考资料16的第11页看到。concurrent mode failure和promotion failed触发的Full GC有啥不同？(这个问题是我、阿飞、蒋晓峰一起讨论的结果)答：concurrent mode failure触发的"Full GC"不是我们常说的Full GC——正常的Full GC其实是整个gc过程包括ygc和cms gc。也就是说，这个问题本身是有问题的，concurrent mode failure的时候触发的并不是我们常说的Full GC。然后再去讨论一个遗漏的知识点：CMS gc的并发周期有两种模式：foreground和background。concurrent mode failure触发的是foreground模式，会暂停整个应用，会将一些并行的阶段省掉做一次老年代收集，行为跟Serial-Old的一样，至于在这个过程中是否需要压缩，则需要看三个条件：（1）我们设置了UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction，前者设置为true，后者默认是0，前者表示是在Full GC的时候执行压缩，后者表示是每隔多少个进行压缩，默认是0的话就是每次Full GC都压缩；（2）用户调用了System.gc()，而且DisableExplicitGC没有开启；（3）young gen报告接下来如果做增量收集会失败。promotion failed触发的是我们常说的的Full GC，对年轻代和老年代都会回收，并进行整理。promotion failed和concurrent mode failure的触发原因有啥不同？promotion failed是说，担保机制确定老年代是否有足够的空间容纳新来的对象，如果担保机制说有，但是真正分配的时候发现由于碎片导致找不到连续的空间而失败；concurrent mode failure是指并发周期还没执行完，用户线程就来请求比预留空间更大的空间了，即后台线程的收集没有赶上应用线程的分配速度。什么情况下才选择使用CMS收集器呢？我之前的观念是：小于8G的都用CMS，大于8G的选择G1。蒋晓峰跟我讨论了下这个观念，提出了一些别的想法，我觉得也有道理，记录在这里：除了看吞吐量和延时，还需要看具体的应用，比方说ES，Lucene和G1是不兼容的，因此默认的收集器就是CMS，具体见可参考资料17和18。小于3G的堆，如果不是对延迟有特别高的需求，不建议使用CMS，主要是由于CMS的几个缺点导致的：（1）并发周期的触发比例不好设置；（2）抢占CPU时间；（3）担保判断导致YGC变慢；（4）碎片问题，更详细的讨论参见资料19。本文作者：杜琪阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

项目简介lightCMS是一个轻量级的CMS系统，也可以作为一个通用的后台管理框架使用。lightCMS集成了用户管理、权限管理、日志管理、菜单管理等后台管理框架的通用功能，同时也提供模型管理、分类管理等CMS系统中常用的功能。lightCMS的代码一键生成功能可以快速对特定模型生成增删改查代码，极大提高开发效率。lightCMS基于Laravel 5.5开发，前端框架基于layui。功能点一览后台：基于RBAC的权限管理管理员、日志、菜单管理分类管理配置管理后台可自定义业务模型，方便垂直行业快速开发基于Tire算法的敏感词过滤系统（待完善）普通模型增删改查代码一键生成前台：用户注册登录（包括微信、QQ、微博三方登录）更多功能待你发现~项目地址：https://github.com/eddy8/ligh…

并非所有程序员都是伟大的设计师（实际上我认识的大部分程序员审美都很要命）。所以即使你心血来潮想为自己开发的网站做一把设计，但显然并不是所有用户想为此付钱。。所以在找不到靠谱的美工的时候，还是老老实实的看看有没有现成的资源可以利用吧。以下是各种网站主题的绝佳资源，从通用主题、后台管理到电商系统。1. HTML5 UpHTML5 Up 有40～50个非常好的简单但优雅的HTML5 / CSS3主题。他们的大多数主题都是通用的，你可以将它们用于任何类型的网站或应用程序。这些主题有很好的响应式设计，在移动设备上看起来很棒，并且完全可定制，并且在Creative Common License下完全免费。每个主题都提供了在线演示，顶部有一个导航栏，可以显示桌面，平板电脑和移动设备的外观。我喜欢这些主题简洁的设计，很易于使用。相比而言，有些付费主题却更加复杂难用。程序员都喜欢简单！2. Start BootstrapStart Bootstrap当然是Bootstrap主题。里面都是最新的bootstrap4主题，很好的入门主题。提供了最精简的模版让你你可以轻松自定义。他们还提供非常好看的后台管理的模版。因此，如果要构建类似博客或CMS的东西，那么你可以找到非常好看的前端界面。我在使用PHP Codeigniter以及Node和Express.js构建的项目中使用了admin主题。如果免费选择不够，他们还提供更好看的高级主题。像大多数此类网站一样，你可以在下载之前预览主题。3. Templated.coTemplated.co是免费HTML5主题的另一个重要资源。拥有近900个免费主题的集合，这些主题在Creative Commons License下是免费的。主题都非常通用，支持在线预览。他们有一些不错的网格库类型主题，适合作为图像分享网站的主题。4. Free HTML5freehtml5.co有付费的高级主题，但是也有很多很棒的免费主题。有许多通用主题以及从律师事务所到摄影主题。许多主题也有很好的动画。有些是纯HTML，有些是Bootstrap的。5. ColorlibColorlib是一个很棒的网站，他们有很多免费主题。有一些独特的类别，如医疗和旅行为主题。也有一些不错的房地产主题，其中一个我几乎用于我的Django课程的房地产应用程序，但最终我决定创建自己的。他们有大量标准的HTML5主题以及一些非常酷的Wordpress主题。他们的实时预览浏览器易于使用，你可以快速测试每个主题。6. Zero ThemeZeroTheme有120多个免费主题可供选择，它们都是响应式的。其中87个是HTML，37个是Bootstrap 4，都提供了桌面版和移动版的预览。在我看来，很多设计看起来非常相似，但你可能会找到你喜欢的东西。7. StyleshoutStyleshout有一些非常好看的响应式主题。他们有一些单页主题，这使它们很容易自定义。他们甚至有“敬请期待”和“404页面”的主题，这真的很酷。他们的许多主题都用JavaScript实现了一些动态的效果，如倒计时和滑块。他们还提供定制化服务，如果您需要定制，您可以支付费用并让他们这样做，这对非开发人员来说非常好。8. HTML5xCSS3html5xcss3.com有不同类别的有大约500个免费主题。其中许多都是基于Bootstrap的。他们也有一些Wordpress主题。这些设计并不具有超级创意，但它们看起来非常简单易用，可以自定义满足你的大部分需求。他们也有一些付费的高级主题。9. 后台管理主题Athemes有一篇文章展示了20多个非常好的后台管理系统主题。这些管理面板设计得很好，很多都具有动态功能，如图表和弹窗。大多数是基于Bootstrap的，有一些基于Material Design和常规HTML5。10. 电商主题Themewagon有一篇文章推荐了很多的HTML5和Bootstrap 4电商主题。范围从服装、家具到电子产品。也有很多是通用的，可用于任何网上店铺。无论您是从头开始构建电商系统还是使用Magento之类的东西，这些主题或多或少都可以帮助你搭建出一个漂亮的电商网站。提示以上资源国内访问较慢，翻墙比较快。

GC参数配置-XX:+PrintGC输出GC日志。-verbose:gc可以认为 -verbose:gc 是 -XX:+PrintGC 的别名。-Xloggc:log/gc.log输出GC日志的存储路径。-XX:+PrintGCDetails输出GC的详细日志。-XX:+PrintGCDateStamps输出GC的时间戳（以日期的形式）。-XX:+ExplicitGCInvokesConcurrent无论什么时候调用系统GC，都执行CMS GC，而不是Full GC。-XX:+PrintHeapAtGC在进行GC的前后打印出堆的信息。-Xms512m设置初始堆的大小。-Xmx512m堆分配的最大空间。-Xmn1024m设置年轻代大小。整个JVM内存大小 = 年轻代大小 + 年老代大小 + 持久代大小，持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。-Xss320K设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。-XX:+UseConcMarkSweepGC使用CMS收集器，其它类似。-XX:NewRatio=4设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5，默认值是2即老年代是新生代内存的2倍-XX:SurvivorRatio=4设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6，默认值为8。-XX:MaxPermSize=16m设置持久代大小为16m。-XX:MaxTenuringThreshold=0设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。 GC[Allocation Failure]表示向young generation(eden)给新对象申请空间，但是young generation(eden)剩余的合适空间不够所需的大小导致的minor gc。2. Minor GC: UseParNewGC 回收日志2018-12-29T14:39:40.102+0800: 3.856: [GC (Allocation Failure) 2018-12-29T14:39:40.102+0800: 3.856: [ParNew: 681600K->72044K(766784K), 0.0977206 secs] 681600K->72044K(4109120K), 0.0978554 secs] [Times: user=0.39 sys=0.06, real=0.10 secs]2018-12-29T14:39:40.102+0800 本次gc触发的时间3.856 jvm启动后所经历的秒数GC (Allocation Failure) 对象分配在新生代但空间不够导致触发一次新生代gcParNew 表示这是新生代gc类型, 即ParNewGC681600K->72044K(766784K), 0.0977206 secs 触发新生代gc时年轻代堆的大小，回收后的年轻代堆的大小，年轻代堆的总大小，该次gc回收所耗费的时间681600K->72044K(4109120K) 回收前堆的总大小，回收后堆的总大小，堆的总大小3. Major GC: UseConcMarkSweepGC 垃圾收集CMS垃圾收集器总共分为7个阶段，其中有2个结算，即是初始标记和最终标记阶段，是需要暂停用户线程的，其余垃圾收集线程均有用户线程并发执行。3.1 Phase 1: Initial Mark 初始标记2018-12-29T14:46:45.247+0800: 429.000: [GC (CMS Initial Mark) [1 CMS-initial-mark: 17305K(3342336K)] 607785K(4109120K), 0.0704856 secs] [Times: user=0.32 sys=0.10, real=0.07 secs] 这是CMS中两次stop-the-world事件中的一次。它有两个目标：一是标记老年代中所有的GC Roots；二是标记被年轻代中活着的对象引用的对象。[1 CMS-initial-mark 收集阶段，开始收集所有的GC Roots和直接引用到的对象17305K(3342336K) 当前老年代的使用情况，老年代可用容量607785K(4109120K) 当前整个堆的使用情况，整个堆的容量，即是整个堆 - 老年代 = 新生代(4109120 - 3342336 = 766784)3.2 Phase 2: Concurrent Mark 并发标记2018-12-29T14:46:45.317+0800: 429.071: [CMS-concurrent-mark-start]2018-12-29T14:46:45.326+0800: 429.080: [CMS-concurrent-mark: 0.009/0.009 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]这个阶段会遍历整个老年代并且标记所有存活的对象，从“初始化标记”阶段找到的GC Roots开始。并发标记的特点是和应用程序线程同时运行。并不是老年代的所有存活对象都会被标记，因为标记的同时应用程序会改变一些对象的引用等CMS-concurrent-mark 并发收集阶段，这个阶段会遍历整个年老代并且标记活着的对象0.009/0.009 secs 展示该阶段持续的时间和时钟时间3.3 Phase 3: Concurrent Preclean 并发预清除2018-12-29T14:46:45.326+0800: 429.080: [CMS-concurrent-preclean-start]2018-12-29T14:46:45.338+0800: 429.092: [CMS-concurrent-preclean: 0.012/0.012 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]这个阶段又是一个并发阶段，和应用线程并行运行，不会中断他们。前一个阶段在并行运行的时候，一些对象的引用已经发生了变化，当这些引用发生变化的时候，JVM会标记堆的这个区域为Dirty Card(包含被标记但是改变了的对象，被认为"dirty")，这就是 Card Marking。在pre-clean阶段，那些能够从dirty card对象到达的对象也会被标记，这个标记做完之后，dirty card标记就会被清除了一些必要的清扫工作也会做，还会做一些final remark阶段需要的准备工作CMS-concurrent-preclean 这个阶段负责前一个阶段标记了又发生改变的对象标记3.4 Phase 4: Concurrent Abortable Preclean 可终止的并发预清理2018-12-29T14:46:45.338+0800: 429.092: [CMS-concurrent-abortable-preclean-start]CMS: abort preclean due to time 2018-12-29T14:46:50.484+0800: 434.238: [CMS-concurrent-abortable-preclean: 4.232/5.146 secs] [Times: user=5.49 sys=0.10, real=5.15 secs] 又一个并发阶段不会停止应用程序线程。这个阶段尝试着去承担STW的Final Remark阶段足够多的工作。这个阶段持续的时间依赖好多的因素，由于这个阶段是重复的做相同的事情直到发生aboart的条件（比如：重复的次数、多少量的工作、持续的时间等等）之一才会停止CMS-concurrent-abortable-preclean 可终止的并发预清理这个阶段很大程度的影响着即将来临的Final Remark的停顿，有相当一部分重要的 configuration options 和 失败的模式3.5 Phase 5: Final Remark 最终标记2018-12-29T14:46:50.485+0800: 434.239: [GC (CMS Final Remark) [YG occupancy: 632074 K (766784 K)]2018-12-29T14:46:50.485+0800: 434.239: [Rescan (parallel) , 0.0791637 secs]2018-12-29T14:46:50.564+0800: 434.318: [weak refs processing, 0.0001243 secs]2018-12-29T14:46:50.565+0800: 434.318: [class unloading, 0.0409380 secs]2018-12-29T14:46:50.605+0800: 434.359: [scrub symbol table, 0.0136356 secs]2018-12-29T14:46:50.619+0800: 434.373: [scrub string table, 0.0015586 secs][1 CMS-remark: 17305K(3342336K)] 649380K(4109120K), 0.1370772 secs] [Times: user=0.46 sys=0.06, real=0.13 secs] 这个阶段是CMS中第二个并且是最后一个STW的阶段。该阶段的任务是完成标记整个年老代的所有的存活对象。由于之前的预处理是并发的，它可能跟不上应用程序改变的速度，这个时候，STW是非常需要的来完成这个严酷考验的阶段。通常CMS尽量运行Final Remark阶段在年轻代是足够干净的时候，目的是消除紧接着的连续的几个STW阶段CMS Final Remark 收集阶段，这个阶段会标记老年代全部的存活对象，包括那些在并发标记阶段更改的或者新创建的引用对象YG occupancy: 632074 K (766784 K) 年轻代当前占用的情况和容量Rescan (parallel) 这个阶段在应用停止的阶段完成存活对象的标记工作weak refs processing 第一个子阶段，随着这个阶段的进行处理弱引用class unloading 第二个子阶段, 类的卸载scrub symbol table 最后一个子阶段, 清理字符引用等1 CMS-remark: 17305K(3342336K) 在这个阶段之后老年代占有的内存大小和老年代的容量649380K(4109120K) 在这个阶段之后整个堆的内存大小和整个堆的容量通过以上5个阶段的标记，老年代所有存活的对象已经被标记并且现在要通过Garbage Collector采用清扫的方式回收那些不能用的对象了3.6 Phase 6: Concurrent Sweep 并发清除2018-12-29T14:46:50.622+0800: 434.376: [CMS-concurrent-sweep-start]2018-12-29T14:46:50.635+0800: 434.388: [CMS-concurrent-sweep: 0.012/0.012 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 和应用线程同时进行，不需要STW。这个阶段的目的就是移除那些不用的对象，回收他们占用的空间并且为将来使用。CMS-concurrent-sweep 这个阶段主要是清除那些没有标记的对象并且回收空间3.7 Phase 7: Concurrent Reset 并发重置2018-12-29T14:46:50.635+0800: 434.388: [CMS-concurrent-reset-start]2018-12-29T14:46:50.651+0800: 434.405: [CMS-concurrent-reset: 0.016/0.016 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 这个阶段并发执行，重新设置CMS算法内部的数据结构，准备下一个CMS生命周期的使用CMS-concurrent-reset 这个阶段重新设置CMS算法内部的数据结构，为下一个收集阶段做准备JVM调优——之CMS GC日志分析