暂时未有相关云产品技术能力~
公众号:小盒子的技术分享
Sunny软件公司欲开发一套界面皮肤库,可以对Java桌面软件进行界面美化。为了保护版权,该皮肤库源代码不打算公开,而只向用户提供已打包为jar文件的class字节码文件。用户在使用时可以通过菜单来选择皮肤,不同的皮肤将提供视觉效果不同的按钮、文本框、组合框等界面元素。
23种设计模式,可以分为三类:创建型模式、行为型模式、结构型模式
23种设计模式,可以分为三类:创建型模式、行为型模式、结构型模式
TCP要求系统资源较多,UDP较少 TCP向上层提供面向连接的可靠服务 ,UDP向上层提供无连接不可靠服务。 虽然 UDP 并没有 TCP 传输来的准确,但是也能在很多实时性要求高的地方有所作为 对数据准确性要求高,速度可以相对较慢的,可以选用TCP
java的类之间的关系:泛化、依赖、关联、实现、聚合、组合
无服务器架构是基于互联网的系统,它的应用开发不使用常规的服务进程。相反,它仅依赖于第三方服务(例如 AWS Lambda 服务),是客户端逻辑和服务托管远程过程调用的组合
横向扩展(scale out)也叫水平扩展,指用更多的节点支撑更大量的请求。例如如果1台机器支撑10 000TPS,那么两台机器是否能支撑20 000TPS? 纵向扩展(scale up)也叫垂直扩展,扩展一个点的能力支撑更大的请求,它通常通过提升硬件实现,例如把磁盘升级为SSD。
可靠性公式:A=MTBF /(MTBF+MTTR)。其中,MTBF的全称是Mean Time Between Failure,即平均无故障工作时间,指上一次故障恢复后开始正常运行到这次故障的时间平均值。MTTR的全称是Mean Time ToRepair,即平均故障修复时间,是指从出现故障到完全恢复的这段时间。
抛开具体业务需求和场景谈论技术方案,无异于纸上谈兵。没有哪一项技术或解决方案有绝对的好坏、优劣之分。都是相对意义上的区分,否则这些项技术或方案是怎么产生的?一定也是为了解决某类具体场景的问题而产生的,在彼时彼刻都可谓 “先进”技术。
学习Netty时 看到Netty高性能的原因之一是使用零拷贝技术 学习Kafka时 看到其高性能的原因之一也使用了零拷贝技术 那么到底什么是零拷贝?本文简单做个描述。
微服务架构并不是什么技术创新,而是开发过程发展到一定阶段对技术架构的要求,是在实践中不断摸索而来的。
通过依赖的管理,我们能够知道,当前系统调用了哪些服务,被哪些服务调用。接下来,我们便可以根据当前系统所依赖的服务,以及系统的流程,判断依赖的服务是否影响应用的流程,以此来决定当前应用依赖的优先级。
观察任何一个企业都可以从三个角度出发,这三个角度分别是技术、流程、文化,三个方面都做好才能成为伟大的企业。Cloud Native也一样,需要从架构、研发流程、团队文化三个角度来实现,三者需要相互配合,缺一不可。
库存可以以数量为单元,假如有5台手机,那么库存就是 5 ,卖掉一台,库存就减 1 变成 4 。这种以数量为单位进行的库存计算相对比较简单,在架构设计中无论你优化DB中的SQL,还是存储结构,或者引入Redis做缓存都比较好设计和实现。
hotspot内置两个编译器C1和C2,解释器和编译器搭配使用的方式在虚拟机中称为“混合模式”(Mixed Mode) c1编译器获取更快的编译速度,c2获取更高的编译质量。
JVM在内存新生代Eden Space中开辟了一小块线程私有的区域,称作TLAB(Thread-local allocation buffer)。默认设定为占用Eden Space的1%。在Java程序中很多对象都是小对象且用过即丢,它们不存在线程共享也适合被快速GC,所以对于小对象通常JVM会优先分配在TLAB上,并且TLAB上的分配由于是线程私有所以没有锁开销。因此在实践中分配多个小对象的效率通常比分配一个大对象的效率要高。
介绍 Git 动画教程的学习方法。
G1收集器之所以能建立可预测的停顿时间模型,是因为它将Region作为单次回收的最小单元,即每次收集到的内存空间都是Region大小的整数倍,这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集。更具体的处理思路是让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小,价值即回收所获得的空间大小以及回收所需时间的经验值,然后在后台维护一个优先级列表,每次根据用户设定允许的收集停顿时间(使用参数-XX:MaxGCPauseMillis指定,默认值是200毫秒),优先处理回收价值收益最大的那些Region,这也就是“Garbage First”名字的由来。
Garbage First(简称G1)收集器是垃圾收集器技术发展历史上的里程碑式的成果,它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。被Oracle官方称为“全功能的垃圾收集器”(Fully-Featured GarbageCollector)。JDK 9服务端模式下的默认垃圾收集器,而CMS则沦落至被声明为不推荐使用(Deprecate)的收集器。本文将对G1进行简单的介绍。
计数排序不是基于比较的排序算法,其核心在于将输入的数据值转化为键存储在额外开辟的数组空间中。作为一种线性时间复杂度的排序,计数排序要求输入的数据必须是有确定范围的整数。 计数排序是一个稳定的排序算法。当输入的元素是 n 个 0到 k 之间的整数时,时间复杂度是O(n+k),空间复杂度也是O(n+k),其排序速度快于任何比较排序算法。当k不是很大并且序列比较集中时,计数排序是一个很有效的排序算法。
堆排序(Heapsort)是指利用堆这种数据结构所设计的一种排序算法。堆积是一个近似完全二叉树的结构,并同时满足堆积的性质:即子结点的键值或索引总是小于(或者大于)它的父节点。堆排序可以说是一种利用堆的概念来排序的选择排序。分为两种方法: 大顶堆:每个节点的值都大于或等于其子节点的值,在堆排序算法中用于升序排列; 小顶堆:每个节点的值都小于或等于其子节点的值,在堆排序算法中用于降序排列; 堆排序的平均时间复杂度为 Ο(nlogn)。
快速排序(有时称为分区交换排序)是一种有效的排序算法。由英国计算机科学家Tony Hoare于1959年开发并于1961年发表,它仍然是一种常用的排序算法。如果实施得当,它可以比主要竞争对手(合并排序和堆排序)快两到三倍。快速排序基本上被认为是相同数量级的所有排序算法中,平均性能最好的。
十种常见排序算法可以分为两大类: 比较类排序:通过比较来决定元素间的相对次序,由于其时间复杂度不能突破O(nlogn),因此也称为非线性时间比较类排序。 非比较类排序:不通过比较来决定元素间的相对次序,它可以突破基于比较排序的时间下界,以线性时间运行,因此也称为线性时间非比较类排序。
我知道很多人对于学习,尤其是算法学习是有一些心理障碍,或者缺乏信念,关于如何保持坚定的信念可以看看这篇:别高估自己1年的成就,却低估自己10年的发展
分派调用则可能是静态的也可能是动态的,根据分派依据的宗量数(方法的调用者和方法的参数统称为方法的宗量)又可分为单分派和多分派。两类分派方式两两组合便构成了静态单分派、静态多分派、动态单分派、动态多分派四种分派情况。
Java编译器输出的指令流,基本上是一种基于栈的指令集架构,而与之相对的另外一套常用的指令集架构是基于寄存器的指令集。早期的android,即android4.4之前使用的JVM是Dalvik VM,就是基于寄存器架构的。
很多公司都会面试算法题,然而很多小伙伴平时工作很忙,没有时间或没有养成刷题的习惯,面试准备周期时间也很紧张,没办法刷完LeetCode,往往慌慌张张刷了一些题,然而其实效果也不好。 当然这里还是建议大家平时多看看算法题,毕竟程序=数据结构+算法,对你以后的编程工作来说是大有好处的。
前后端分离后,前端打开控制台一看,怎么有时请求一个后端接口发了两次请求? 那个options是啥? 很有可能是因为你发送的是CORS请求(CORS是一个W3C标准,全称是"跨域资源共享"(Cross-origin resource sharing)),且是非简单请求。 浏览器将CORS请求分成两类:简单请求(simple request)和非简单请求(not-so-simple request)。
MaxProcessMemory:如32位的linux默认每个进程最多申请3G的地址空间,64位的操作系统可以支持到46位(64TB)的物理地址空间和47位(128T)的进程虚拟地址空间(linux 64位CPU内存限制)。 JVM内存:由Heap区和Perm区组成。通过-Xms和-Xmx可以指定heap区大小,通过-XX:PermSize和-XX:MaxPermSize指定perm区的大小(默认从32MB 到64MB,和JVM版本有关)。
我们知道java中基本类型byte占8 bits,取值范围是-128到最+127,从这个正负号大家也能看出表示这个范围的二进制数是有符号位的,就是第一位。
有了Unicode 字符集后,我们要考虑的就是以什么样的方式对这些字符进行传输和存储,这就是 Unicode 编码的实现方式,我们称为 Unicode 转换格式(Unicode Transformation Format,简称 UTF)。我们熟悉的 UTF-8、 UTF-16 等就是不同的 Unicode编码实现方式。
在 Debug 领域,JDK 有一套规范与体系来支持,即 Java Platform Debugger Architecture,JPDA 体系。在 JPDA 体系中定义了 三个角色,每个角色又对应着不同的技术模块支撑,分别为 JVMTI/JDWP/JDI。
java Io流共涉及40多个类,这些类看上去很杂乱,但实际上很有规则,而且彼此之间存在非常紧密的联系, Java Io流的40多个类都是从如下4个抽象类基类中派生出来的。