首页 文章 精选 留言 我的

精选列表

搜索[java ee],共10000篇文章
优秀的个人博客,低调大师

Java中设计模式的概述(设计模式是经验的总结)

设计模式 A:设计模式的概述(设计模式是经验的总结) 设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 设计模式不是一种方法和技术,而是一种思想。 设计模式和具体的语言无关,学习设计模式就是要建立面向对象的思想,尽可能的面向接口编程,低耦合,高内聚,使设计的程序可复用。 学习设计模式能够促进对面向对象思想的理解,反之亦然,它们相辅相成。 B:设计模式的几个要素 名字:必须有一个简单、有意义的名字。 问题:描述在何时使用模式。 解决方案:描述设计的组成部分以及如何解决问题。 效果:描述模式的效果以及优缺点。 C:设计模式的分类 创建型模式 对象的创建 结构型模式 对象的组成(结构) 行为型模式 对象的行为 创建型模式:简单工厂模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式、单例模式。(6个) 结构型模式:外观模式、适配器模式、代理模式、装饰模式、桥接模式、组合模式、享元模式。(7个) 行为型模式:模版方法模式、观察者模式、状态模式、职责链模式、命令模式、访问者模式、策略模式、备忘录模式、迭代器模式、解释器模式。(10个)我的GitHub地址: https://github.com/heizemingjun 我的博客园地址: http://www.cnblogs.com/chenmingjun 我的蚂蚁笔记博客地址: http://blog.leanote.com/chenmingjun Copyright ©2018 黑泽明军 【转载文章务必保留出处和署名,谢谢!】

优秀的个人博客,低调大师

java多用户商城系统源码架构篇——分库分表

目前公司数据量已经上来,单表最大已经5千万,之前使用分区表,用起来有很多需要注意的地方,以及坑等。所以就在年后准备做分库分表,筛选了N多中间件、框架,似乎都不满足。主要在以下几点。比如用阿里的myCat,需要学习、研究,因为我们目前有点急,需要安排人去研究,而且需要深入研究,结果就是搞了几天没啥头绪。但是原理就是做代理,这个了解透了。在看当当网提供的sharding-jdbc分库分表案例,也是同样问题,没那么多时间研究,而且这几家提供的东西,居然官网都是英文/中文,中文文档也是按照老外风格写,尽量给你增加门槛!!! 于是乎就萌生自己写分库分表。废话不多说。1、首先是老数据问题,这个是网上所有文章没有提到的,没有提到这个问题的文章,可以说99.99%没玩过分库分表。对于5000万的数据量,做切分,一张表控制在100万,你手动去复制粘贴???,每隔一段时间手动建库???据说当当是手动,应该是写的程序手动的。。。。伤不伤???其实很简单,我用JDBC写的,查到老库所有表名,create table newTableName like oldTableName;这样可以把表结构、索引结构都拷贝过来到新库,但是不会拷贝数据,网上有另一条SQL,我想大家已经玩过了,那个索引、主键不会拷贝。。2、如何做数据分散存储很多人肯定看过文章,ID取模呀。那如果数据量又达到瓶颈咋搞?阿里的单表12年就已经100亿了。。。。所以说ID取模并不是仅仅这么简单,还需要数据量控制,我这里有个更好办法,其实就是简单数据量控制。达到100万就Next,ID是自增的,出去100万,余数为0则Next。当然ID取模这么流行的方法都是阿里、58、京东这些架构师出来讲培训说的,其实你实际去操作,有其他N多方法,没有必要照搬。。。。3、多表、关联关系如何建立?你怎么知道User表包含哪些Order表呢?,如果一个user出的订单既有在N库,也有在N+1、N+2库里面呢?通过user_id查询order。一般单库做关联查询,其实多库也可以,只是索引会失效而已了。然后2千万*5千万扫描。。。。我看过唯品会的解决方案,他们是Order_id中间一段是user_id,完美不,很完美。。。。但是,我们已经有5000万数据了,人家唯品会有的是钱,拉500人团队搞呗。。。2个月搞完。我们几个人?就是我一个人。。。。伤不伤吧。。所以这个方案不行,唯品会文章中丢弃的一个方案就是建立中间对应关系。就是user_id和order_联合加上order_id所在库。他们丢弃的原因是中间表会巨大,确实。但是如果放在redis缓存中就没有这个问题了,redis缓存只要空间足够大,性能2~3个亿没问题。redis缓存还可以做切分啊,也算是完美符合我们这种小公司了吧。 4、如何取数据?对于一对一查询,以前关联查询、子查询,现在都用子查询,分为两次查询。这个时间上只是毫秒差异。不用联合多库查询。(题外话,做互联网公司项目,几乎不会需要用外键、关联查询的。。。一般都是分多次查询,或者通过缓存系统拿空间换时间,怎么玩?比如微博一个用户发文章,不做文章表,所有文章放在user的下面,每个user下面都是自己的,那么查询起来就是查user就OK。)对于一对多查询,就是2里面提到的,已经知道库了,那么具体查询方案我们还是多次查询。对于多对多,更简单了,中间关系建立好,比以前多对多查询更简单了。这会还是一对多查询。 以上就是我们对于分库分表的解决方案。其实分库分表非常简单。我一个人搞了一个月吧。。。 如果你需要电商,B2B2C商城系统,并且支持分布式、分库分表,可以联系我探讨。其实有N多解决方案,最好是团队讨论,更方便沟通,文章也不能全部说出来,我写的过程遇到过N多有意思的事情以及各个框架急需提供对于扩展大数据量的问题。。。

优秀的个人博客,低调大师

基于JAVA的模块化开发框架JarsLink

需求背景 应用拆分的多或少都有问题。多则维护成本高,每次发布一堆应用。少则拆分成本高,无用功能很难下线。 故障不隔离。当一个系统由多人同时参与开发时,修改A功能,可能会影响B功能,引发故障。 多分支开发引发冲突。多分支开发完之后合并会产生冲突。 牵一发动全身。一处核心代码的改动,或一个基础Jar的升级需要回归整个系统。 升级和迁移成本高。中间件升级每个应用都有升级成本。 模块化开发的好处 可插拔,一个应用由多个模块组成,应用里的模块可拆和合,模块可快速在多个系统中迁移和部署。 模块化开发,模块之间互相隔离,实现故障隔离。 一个模块一个分支,不会引发代码冲突。 在模块中增加或修改功能,只会影响当前模块,不会影响整个应用。 动态部署,在运行时把模块部署到应用中,快速修复故障,提高发布效率。 多版本部署,可以在运行时同时部署某个模块的新旧版本,进行AB TES

优秀的个人博客,低调大师

java面试-深入理解JVM(六)——JVM性能调优实战

如何在高性能服务器上进行JVM调优? 为了充分利用高性能服务器的硬件资源,有两种JVM调优方案,它们都有各自的优缺点,需要根据具体的情况进行选择。 1. 采用64位操作系统,并为JVM分配大内存 我们知道,如果JVM中堆内存太小,那么就会频繁地发生垃圾回收,而垃圾回收都会伴随不同程度的程序停顿,因此,如果扩大堆内存的话可以减少垃圾回收的频率,从而避免程序的停顿。 因此,人们自然而然想到扩大内存容量。而32位操作系统理论上最大只支持4G内存,64位操作系统最大能支持128G内存,因此我们可以使用64位操作系统,并使用64位JVM,并为JVM分配更大的堆内存。但问题也随之而来。 堆内存变大后,虽然垃圾收集的频率减少了,但每次垃圾回收的时间变长。如果对内存为14G,那么每次Full GC将长达数十秒。如果Full GC频繁发生,那么对于一个网站来说是无法忍受的。 因此,对于使用大内存的程序来说,一定要减少Full GC的频率,如果每天只有一两次Full GC,而且发生在半夜, 那完全可以接受。 要减少Full GC的频率,就要尽量避免太多对象进入老年代,可以有以下做法: 确保对象都是“朝生夕死”的一个对象使用完后应尽快让他失效,然后尽快在新生代中被Minor GC回收掉,尽量避免对象在新生代中停留太长时间。 提高大对象直接进入老年代的门槛通过设置参数-XX:PretrnureSizeThreshold来提高大对象的门槛,尽量让对象都先进入新生代,然后尽快被Minor GC回收掉,而不要直接进入老年代。 注意:使用64位JDK的注意点 64位JDK支持更大的堆内存,但更大的堆内存会导致一次垃圾回收时间过长。 现阶段,64位JDK的性能普遍比32位JDK低。 堆内存过大无法在发生内存溢出时生成内存快照若将堆内存设为10G,那么当堆内存溢出时就要生成10G的大文件,这基本上是不可能的。 相同程序,64位JDK要比32位JDK消耗更大的内存 2. 使用32位JVM集群 针对于64位JDK种种弊端,我们更多选择使用32位JDK集群来充分利用高性能机器的硬件资源。 如何实现? 在一台服务器上运行多个服务器程序,这些程序都运行在32位的JDK上。然后再运行个服务器作为反向代理服务器,由它来实现负载均衡。由于32位JDK最多支持2G内存,因此每个虚拟结点的堆内存可以分配1.6G,一共运行10个虚拟结点的话,这台物理服务器可以拥有16G的堆内存。 有啥弊端? 多个虚拟节点竞争共享资源时容易出现问题如多个虚拟节点共同竞争IO操作,很可能会引起IO异常。 很难高效地使用资源池如果每个虚拟节点使用各自的资源池,那么无法实现各个资源池的负载均衡。如果使用集中式资源池,那么又存在竞争的问题。 每个虚拟节点最大内存为2G 别忘了直接内存也可能导致内存溢出! 问题描述 有个小型网站,使用32位JDK,堆1.6G。运行期间发现老是出现内存溢出。为了判断是否是堆内存溢出,在程序运行前添加参数:-XX:+HeapDumpOnOutOfMemeryError(添加这个参数后当堆内存溢出时就会输出异常日至)。但当再次发生内存溢出时,没有生成相关异常日志。从而可以判定,不是堆内存发生溢出。 问题分析 我们可以发现,在32位JDK中,将1.6G分配给了堆,还有一部分分配给了JVM的其它内存,只有少于0.4G的内存为非JVM内存。我们知道,如果使用了NIO,那么JVM会在JVM内存之外分配内存空间,这部分内存也叫“直接内存”。因此,如果程序中使用了NIO,那么就要小心“直接内存”不足时发生内存溢出异常了! 直接内存的垃圾回收过程 直接内存虽然不是JVM内存空间,但它的垃圾回收也有JVM负责。直接内存的垃圾回收发生在Full GC时,只有当老年代内存满时,垃圾收集器才会顺便收集一下直接内存中的垃圾。如果直接内存已满,但老年代没满,这时直接内存先是抛出异常,相应的catch块中调用System.gc()。由于System.gc()只是建议JVM回收,JVM可能不马上回收内存,那么这时直接内存就抛出内存溢出异常,使得程序终止。 JVM崩溃的原因 当内存溢出时,JVM仅仅会终止当前运行的程序,那么什么时候JVM会崩溃呢? 什么是异步请求? 我们知道,Web服务器和客户端采用HTTP通信,而HTTP底层采用TCP通信。异步通信就是当客户端向服务器发送一个HTTP请求后,将这个请求的TCP连接委托给其它线程,然后它转而做别的事,那条被委托的线程保持TCP连接,等待服务器的回信。当收到服务器回信后,再将收到的数据转交给刚才的线程。这个过程就是异步通信过程。 异步请求如何造成JVM崩溃? 如果一个Web应用使用了较多的异步请求(AJAX),每次主线程发送完请求后都将TCP连接交给一条新的线程去等待服务器回信,那么如果网络不流畅时,这些受委托的线程迟迟等不到服务器的回信,因此保持着TCP连接。当TCP连接过多时,超过JVM的承受能力,JVM就发生崩溃。 如何处理大对象? 大对象对于JVM来说是个噩耗。如果对象过大,当前新生代的剩余空间装不下它,那么就需要使用分配担保机制,将当前新生代的对象都复制到老年代中,给大对象腾出空间。分配担保涉及到大量的复制,因此效率很低。 那么,如果将大对象直接放入老年代,虽然避免了分配担保过程,但该对象只有当Full GC时才能被回收,而Full GC的代价是高昂的。如果大对象过多时,老年代很快就装满了,这时就需要进行Full GC,如果Full GC频率过高,程序就会变得很卡。 因此,对于大对象,有如下几种处理方法:1. 在写程序的时候尽量避免大对象从源头降低大对象的出现,尽量选择空间利用率较高的数据结构存储。2. 尽量缩短大对象的有效时间对象用完后尽快让它失效,好让垃圾收集器尽快将他回收,避免因在新生代呆的时间过长而进入老年代。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

用户登录
用户注册