题目描述 给定一个经过编码的字符串，返回它解码后的字符串。 编码规则为: k[encoded_string]，表示其中方括号内部的 encoded_string 正好重复 k 次。注意 k 保证为正整数。 你可以认为输入字符串总是有效的；输入字符串中没有额外的空格，且输入的方括号总是符合格式要求的。 此外，你可以认为原始数据不包含数字，所有的数字只表示重复的次数 k ，例如不会出现像 3a 或 2[4] 的输入。 示例 1： 输入：s = "3[a]2[bc]" 输出："aaabcbc" 示例 2： 输入：s = "3[a2[c]]" 输出："accaccacc" 示例 3： 输入：s = "2[abc]3[cd]ef" 输出："abcabccdcdcdef" 示例 4： 输入：s = "abc3[cd]xyz" 输出："abccdcdcdxyz" 解法： 字符串有多层嵌套的情况，利用栈解决。使用两个栈，一个数字栈，一个字符串栈 public String decodeString(String s) { StringBuilde....
3.编写整洁的代码 是否是整洁的代码，需要遵循一定的方法论，不能靠个人主观的感觉判断。推荐大家看完《代码整洁之道》这本书，遵循这里的原则。 列出一些必须要遵循的原则： 命名 做有意义的区分 区分名称，要使用读者能清洗鉴别出不同之处的方式。禁止类似customerInfo/customer、 user/userInfo、 money/moneyAmount 这种没有区分度的命名 使用可搜索的名称 例：WORK_DAYS_PER_WEEK 很容易搜索，但是数字5就无法搜索了 类名 类名和对象名应该是名词或名词短语。类名不应当是动词。正例：Customer、AddressParser；反例：Manager、Processor、Data 方法名 方法名应当是动词或者动词短语。比如：deletePage/save等 添加有意义的语境 很少有名称能自我说明，你需要良好命名的类、函数和名称空间来放置名称，给读者提供语境。如果没这么做，需要给名称添加前缀。 比如在缺少上下文的情况下，firstName、lastName、street就需要添加前缀addrFirstName、addrLastName、a....
一、数据库中间件设计思路 1.1.背景 最开始学习jdbc的时候，直接通过jdbc就能访问DB。但是这时候缺少了数据源、缺少了ORM框架，不能在生产环境使用，在后期更换DB类型时也存在很大问题。 所以出现了ORM框架。在未进行读写分离/分库分表的情况下，我们是直接在应用中通过数据源(c3p0、druid、dbcp2等)与数据库建立连接，进行读写操作，架构如下所示： ORM框架作用： 隐藏了对象的访问细节 ORM使我们构造固化数据结构变得简单易行 可以看到在操作单库单表的情况下，我们是直接在应用中通过数据源(c3p0、druid、dbcp等)与数据库建立连接，进行读写操作。 随着互联网的发展，数据规模越来越大，分库分表、读写分离成了通用的解决方案。 大部分开发人员对于访问单库的应用的架构都是很熟悉的。但是在进行读写分离/分库分表后，底层的数据库实例就会有多个，读写分离情况下一个master多个slave；分库分表的情况下，有多个不同的分库。 从应用的角度来说，除了要与多个不同的数据库建立连接，还需要处理分库分表/读写分离特定场景下的问题： 在读写分离的情况下，应用需要对读sql/写sql....
对象之间的关系就体现为类之间的关系。类之间存在不同的关系，依赖的强弱也各有不同，从强至弱依次为： 继承关系 → 组合关系 → 协作关系 继承关系 继承关系体现了“泛化-特化”的关系，父类提供更加通用的特征，子类在继承了父类的特征之外，提供了符合自身特性的特殊实现。继承关系在 UML 中使用空心三角形加实线的方式来代表子类继承父类，例如矩形类继承自形状类： 继承会导致子类与父类之间形成一种强耦合关系，父类发生任何变更，都会体现到子类中，形成所谓的“脆弱的基（父）类”。由于继承代表了一种“is”的关系，在领域建模时，父类和子类代表的其实是同一个领域概念的不同层次。 组合关系 组合关系体现了类实例之间整体与部分之间的关系，体现了“has”的概念，即一个类实例“包含了”另一个或多个类实例。组合关系体现了类概念之间的一对一、一对多和多对多关系。依据关系的强弱，组合关系又分别分为“合成（Composition）”关系与“聚合（Aggregation）”关系。前者的关系更强，例如计算机和 CPU 之间就是合成关系，因为离开了 CPU，计算机就不能正常运行；后者的关系较弱，例如计算机和键盘之间就是聚合....
一、分表键的选择 分表键即**分库/分表字段，zebra里面叫做维度，**是在水平拆分过程中用于生成拆分规则的数据表字段。Zebra 根据分表键的值将数据表水平拆分到每个物理分库中。 **拆分主要原则：**需要找到数据库表中的数据在业务逻辑上的主体，并确定大部分或者核心的数据库操作都围绕着这个主体的数据进行。可以使用该主体对应的字段作为分表键，进行分库分表。 业务逻辑上的主体，通常与业务的应用场景相关，下面的一些典型应用场景都有明确的业务逻辑主体，可用于分表键： 面向用户的互联网应用，都是围绕用户维度来做各种操作，那么业务逻辑主体就是用户，可使用用户对应的字段作为分表键； 侧重于卖家的电商应用，都是围绕卖家维度来进行各种操作，那么业务逻辑主体就是卖家，可使用卖家对应的字段作为分表键； **注意：**无论选择什么拆分键，采用何种拆分策略，都要注意拆分值是否存在热点的问题，尽量规避热点数据来选择拆分键。 1.1.多个分表键如何处理 名词解释： **主维度：**主分表键，在主维度上，数据能够增删改查； 辅维度：辅助分表键，在辅助维度上，只能进行数据查询 大部分场景下，一张表的查询条件比较单一....
一、常用命令 内存分析常用命令： // 打印每个class的实例数目,内存占用,类全名信息.live子参数加上后,只统计活的对象数量. 此时会触发FullGC jmap -histo:live <pid> > filename | head -10 // dump 内存 jmap -dump:live,format=b,file=/opt/logs/dump.hprof <pid> // 查看堆栈使用情况 jmap -head pid // 垃圾回收统计概述 jstat -gc <pid> <time> // 垃圾回收统计概述，使用空间占总空间的百分比 jstat -gcutil <pid> <time> // 用于生成java虚拟机当前时刻的线程快照 jstack <pid> 二、问题描述 我们系统中存在一个定时任务，每次执行任务时都会触发full gc，稳定复现。是一个报表计算的任务，会把原始表的数据经过加工整理汇总到指标表，涉及数据大批量插入的情况 三、排查过程 排查思路是：发生fullg....
输入top命令之后： 总共有这些指标： 每个字段具体什么意思呢？ 名称英文解释说明备注 PIDProcess Id进程IDx USERUser Name优先级 PRPriority？ NINice value虚拟镜像 VIRTVirtual Image RESResident size SHRShared Mem size SProcess Status %CPU %MEM TIME+ COMMAND
使用 perf record -g -p 55 开启监控栈函数调用。运行一段时间后Ctrl+C结束，会生成一个文件perf.data。 代码块 Java perf record -g -p pid 执行perf report -i perf.data查看报告。 代码块 Java perf report -i perf.data 参考文档： https://www.ibm.com/developerworks/cn/linux/l-cn-perf1/index.html https://blog.csdn.net/lycyingO/article/details/80854669
1.使用top命令查询Java进程 代码块 SQL top 定位到java进程为369 2.通过top命令定位进程包含的线程信息 代码块 SQL top -H -p 369 -d 1 -n3 查询到线程占用率最高的线程PID 为672 3.通过jstack命令查询线程堆栈 jstack 下的NID为16进制，672对应的16进制为223 代码块 SQL jstack -l 369|grep -A 20 "223" 结果内容为： 至此，可以根据代码去定位问题
模式与操作 模式 模式可以是以下任意一种： 正则表达式：使用通配符的扩展集 关系表达式：使用运算符进行操作，可以是字符串或数字的比较测试 模式匹配表达式：用运算符～（匹配）和~!不匹配 BEGIN 语句块， pattern语句块， END语句块 awk常见命令 NF NF表示字段数量，通过分隔符分割后有多少个字段 代码块 Plain Text printf "1:2:3:4:5:4" | awk -F ":" NF==6'{print $0}' 1:2:3:4:5:4 FS FS表示输入字段分隔符，默认为空格 代码块 Plain Text printf "we are you " | awk 'BEGIN{FS="\t"} {print $1, $2, $3}' we are you RS RS 记录分隔符变量 $n : 当前记录的第n个字段，比如n为1表示第一个字段，n为2表示第二个字段。 $0 : 这个变量包含执行过程中当前行的文本内容。 ARGC : 命令行参数的数目。 ARGIND : 命令行中当前文件的位置（从0开始算）。 ARGV : 包含命令行参数的数组。 CON....
If you already have code ready to be pushed to this repository then run this in your terminal. cd existing-project git init git add --all git commit -m "Initial Commit" git remote add origin ssh://git@git.xxx.com/cyhy/xxxx.git git push origin master If your code is already tracked by Git then set this repository as your origin to push to. cd existing-project git remote set-url origin ssh://git@git.xxx.com/cyhy/xxxx.git git push origin master All done with the commands?
文章链接：https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read 《代码大全》 《程序员修炼之道》 《计算机的构造和解释》 《算法导论》 《设计模式》 《重构》 《人月神话》 《代码整洁之道》 《Effective C++》、《More Effective C++》 《Unix 编程艺术》、《Unix 高级环境编程》 待完善... 练级攻略： 编程语言 理论学科 系统知识 软件设计 Linux 系统、内存、网络 异步 I/O 模型和 Lock-Free 编程 Java 基层知识 数据库 分布式架构入门 微服务 容器化和自动化运维 前端基础和底层原理 前端性能优化和框架 UI/UX 设计
根据美团下一代服务治理系统 OCTO2.0 的探索与实践整理总结而来 一、OCTO现状 OCTO 是美团标准化的服务治理基础设施，治理能力统一、性能及易用性表现优异、治理能力生态丰富，已广泛应用于美团各事业线。但是存在一些问题： 对多语言支持不够好。 美团技术栈使用的语言主要是 Java，占比到达80%以上，上面介绍的诸多治理能力也集中在 Java 体系。 但美团同时还有其他近10种后台服务语言在使用，这些语言的治理生态均十分薄弱，同时在多元业务的模式下必然会有增长的多语言需求，为每一种语言都建设一套完善的治理体系成本很高，也不太可能落地。 中间件和业务绑定在一起，制约着彼此迭代。 一般来说，核心的治理能力主要由通信框架承载，虽然做到了逻辑隔离，但中间件的逻辑不可避免会和业务在物理上耦合在一起。这种模式下，中间件引入Bug需要所有业务配合升级，这对业务的研发效率也会造成损害；新特性的发布也依赖业务逐个升级，不具备自主的控制能力。 异构治理体系技术融合成本很高。 治理决策比较分散。 每个节点只能根据自己的状态进行决策，无法与其他节点协同仲裁。 针对以上痛点，我们考虑依托于 Service....
参考文档： https://yq.aliyun.com/articles/646976 http://hedengcheng.com/?p=771 一篇搞定 MySQL 锁机制面试
B树是为了磁盘或其他直接存取的辅助存储设备而设计的一种平衡搜索树。B树类似于红黑树，但是在降低磁盘IO操作数方面要更好一些。B树与红黑树的不同之处在于B树的结点可以有很多孩子。从几个到几千个都可以。和红黑树一样，有n个结点的B树的高度为O(lgn),然而一个b树的严格高度可能比一颗红黑树要小许多。这就是因为他的分支因子。表示高度的对数的底数可以非常大。 在了解B树之前先必须要弄明白磁盘存储的数据结构和随机访问的主存数据结构的不同。 ##1. 磁盘存储数据结构 一个典型的磁盘驱动器，它包括了n个绕主轴旋转的盘片，每个盘片通过磁臂末端的磁头来读写。这些磁臂围绕着一个共同的旋转轴旋转。当读写磁头静止时，它下方经过的磁盘表面就是一个磁道。磁盘的机械运动相比主存来说是非常慢的。目前磁盘的旋转速度在5400-15000转/分钟。服务器级别（15kRPM），台式机（7200RPM），笔记本（5400RPM）。对台式机来说，旋转一周需要8.33ms。每次读出多个页面。 在一个典型的B树应用中，所要处理的数据量非常大，所有数据无法一次装入内存中。b树算法通常只会在主存中保留一定数量的页面。对我们来说，一....
内容来自网络，非本人原创。 查看原文 一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题，使得分布式哈希（DHT）可以在P2P环境中真正得到应用。 ##1. 判断哈希算法好坏的标准 一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义： 平衡性(Balance): 尽可能分布到所有缓冲中 单调性(Monotonicity): 已经分配好的缓冲，哈希值尽可能少的变动 分散性(Spread): 在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就....