求大神帮助,java存取大图片问题

Stluny 2016-01-16 04:31:55
现在做项目 有个履历的功能需要在画面加载中显示 履历中可以存放图片 我的图片使用BufferImage对象存取的 读取完后我将BufferImage对象置null 并且调用了System.gc()回收对象 但是当图片很大的时候 我测试是20MB的图片 并且有多张图片时 java就会报内存溢出 我看有人说需要优化java所提供的代码 然而我搞不定 伸个手 有没有大神可以解决这个问题至少同时读取20MB的图片 3-5张 不会挂掉。。 求大神
...全文
201 8 打赏 收藏 转发到动态 举报
写回复
用AI写文章
8 条回复
切换为时间正序
请发表友善的回复…
发表回复
daker_129 2016-01-27
  • 打赏
  • 举报
回复
感觉好难,怎么解决的,求分享。。
Stluny 2016-01-21
  • 打赏
  • 举报
回复
放弃结贴。。
Stluny 2016-01-19
  • 打赏
  • 举报
回复
引用 5 楼 Tro_picana 的回复:
设置JVM启动参数-Xmx扩大一些内存,多给点。
这个方法治标不治本啊。。。
小白晒太阳 2016-01-18
  • 打赏
  • 举报
回复
设置JVM启动参数-Xmx扩大一些内存,多给点。
Stluny 2016-01-18
  • 打赏
  • 举报
回复
没有人 难道此贴要终结。。。
Stluny 2016-01-16
  • 打赏
  • 举报
回复
引用 2 楼 panda8101 的回复:
图像分块处理啊,处理完成后再合并。
能不能给个具体的例子 我去试试。。 百度了下还是不太懂怎么分块
panda8101 2016-01-16
  • 打赏
  • 举报
回复
图像分块处理啊,处理完成后再合并。
Stluny 2016-01-16
  • 打赏
  • 举报
回复
对了还有一个问题我都不好意思说。。 给的设计 图片时存在数据库里的 我认为这是个傻逼设计 但是没办法。。 然后这个图片从数据库里取出来就好久 好他妈蠢。。 有没有办法优化下。。 就是从数据库取出来在表示 很慢 还可能会挂。。
#秒杀技术重新梳理 ##redis分布式锁 >首先要了解的乐观锁是什么? > 数据库乐观锁,数据库增加一个版本标识 >redis乐观锁通过watch命令监视给定的key,当exec时候如果监视的key从调用watch后发生过变化,则整个事务失败。也可以调用watch多次监听 >多个Key。 > >Redis事务是一组命令的集合。主要用到两个multi和exec命令。事务开始时向redis服务器发送multi命令,然后依次发送需要在本次事务中处理 >的命令 >1.multi,开启redis的事务 >2.exec,提交事务,执行从multi到此命令前的命令队列 >3.discard,取消事务 >4.watch,监视键值对 ##rabbitmq与kafka的区别 - 为什么要使用消息队列 >解耦:将消息写入消息队列,需要消息的系统从消息队列中订阅 >异步:非必要的业务逻辑以异步方式进行,加快速度 >削峰:不直接访问数据库 - 消息队列的缺点 >系统可用性降低:消息队列可能会挂掉 >系统复杂性增加:加入了消息队列,要考虑一致性问题,如何保证消息不被重复消费,如何保证消息可靠性传输 - rabbitmq >建议中小型公司使用,这种公司数据量不是很大,管理界面很方便,功能完善,社区活跃 - redis >它的pub-sub模式是快产快消的的,全都是因为redis是使用内存来做存取,所有一旦被消费就会丢弃 > >这样的场景可以考虑使用redis:对速度十分看重,允许出现消息丢失的场景,数据量不是很大,不需要保存消息 - kafka >稳定,可以保存,不会丢失数据,速度不需要很快,需要处理的数据量很大,可以进行日志采集 - rocketMq >是java语言开发的,和kafka一样支持分布式架构,可用性和单机吞吐量很高 - 消息不被重复消费(保证消息幂等性) > 正常情况下,消费者在消费完毕时,会发送一个确认消息给消息队列,消息队列就知道消息被消费了,就会将该消息从消息队列中 >删除。不同的消息队列发出的确认消息形式不同,rabbitmq发送的是一个ack确认消息,rocketmq是返回的一个consume_success成功 >标志,kafka则是有个offet的概念。 > >造成重复消息的原因是因为网络传输的故障导致确认消息没有传送到消息队列,导致消息队列不知道自己已经消费这个消息,会再次将 >这个消息发送给消费者 > >解决的思路分为三种情况:第一个是你拿到这个消息做数据库的insert操作,给这个消息做一个唯一的主键; >第二种情况比如你拿这个消息做redis的set操作,那么就不用操作,因为这个操作本身就是幂等的。 >第三种情况可以准备第三方的介质来做消费记录。拿redis举例,给消息分配一个全局id,只要是消费过该记录将以k-v键值对的形式写入redis。在消费者开始消费 >消息之前,查看是否存在消费记录。 - 如何保证消费的可靠性传输 >换种说法就是保证消费不能丢失,无法做到可靠性传输会造成上千万损失? > >要保证可靠性传输需要从三个角度来考虑:第一是生产者弄丢了数据,第二是消息队列弄丢了数据,第三是消费者弄丢了数据 > >第一种情况rabbitmq提供了transaction和confirm模式来确保生产者不会丢失消息 >transaction机制是说发送消息前,开启事务(channel.txSelect()),然后再发送消息,如果发送消息的过程中出现什么异常就回滚 >(channel.txRollback()),如果发送成功就提交事务。这种发送的一个缺点是吞吐量下降. >一般使用的是confirm模式居多,所有在信道上发送的消息都会被指派一个唯一的id,一旦消息被投递到指定的消息队列中去就会发送一个 >ack给生产者,如果没有则发送nack给生产者 > >第二种情况是持久化磁盘,具体是将queue的持久化标识durable设置为true,则代表是一个持久的队列,发送消息的时候讲deliveryMode=2 > >第三是主要消费者采取的是自动确认消息模式?可以改成手动确定的模式,但是这样会造成消息重复消费的情况,主要是看guide的文章发现的 >下面评论的大神解决方案是手动维护偏移量,处理完业务逻辑在提交偏移量,为了保证不造成重复消费,可以将处理业务逻辑和提交偏移量绑定一个事务 > ##redis资源池必须及时关闭

62,612

社区成员

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧