Disabling contextual LOB creation as createClob() method threw error : java.lang

本文解决了在使用Hibernate框架时因未正确配置数据库连接而导致的createClob()方法抛出异常的问题。通过设置属性hibernate.temp.use_jdbc_metadata_defaults为false,可以避免Hibernate尝试从不可用的数据库获取元数据。

Disabling contextual LOB creation as createClob() method threw error : java.lang

[摘要:实在只需看第一止就能够了 at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:244) ,便是正在设置装备摆设的时间出与到值。那末为何出] 

其实只要看第一行就可以了 at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:244) ,就是在配置的时候没取到值。那么为什么没取到值呢,是因为Hibernate默认是使用jdbc方式来取的,如果使用连接池的方式的话,必须告诉Hibernate一声,让它不使用单纯的JDBC连接。加入下面这一句话就可以了。

 Disabling contextual LOB creation as createClob() method threw error : java.lang.reflect.Invocation,同样解决办法

<prop key="hibernate.temp.use_jdbc_metadata_defaults">false</prop>  

这问题也困扰了我好几个小时,下面贴出Hibernate的源码来看一下。


package org.hibernate.engine.jdbc.internal;

[java] view plaincopy
  1. // 'hibernate.temp.use_jdbc_metadata_defaults' is a temporary magic value.  
  2. // The need for it is intended to be alleviated with future development, thus it is  
  3. // not defined as an Environment constant...  
  4. //  
  5. // it is used to control whether we should consult the JDBC metadata to determine  
  6. // certain Settings default values; it is useful to *not* do this when the database  
  7. // may not be available (mainly in tools usage).  
  8. final boolean useJdbcMetadata = ConfigurationHelper.getBoolean( "hibernate.temp.use_jdbc_metadata_defaults", configValues, true );  
  9. if ( useJdbcMetadata ) {  
  10.     try {  
  11.         final Connection connection = jdbcConnectionAccess.obtainConnection();  

大家可以看到,参数在取值的时候,它要先用useJdbcMetadata判断一下,是不是JDBC方式,如果不把这个属性设置为false的话,那么取值必然是取不到了,这就是空指针的原因。


PS:以后开源的东西还是要多看看源码

07-31 10:28:12.932 408 526 D EthernetNetworkFactory: Starting Ethernet IpClient(eth0) 07-31 10:28:12.937 408 430 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.power.PowerManagerService on foreground thread (android.fg) 07-31 10:28:12.938 408 430 W Watchdog: android.fg annotated stack trace: 07-31 10:28:12.938 408 430 W Watchdog: at com.android.server.power.PowerManagerService.monitor(PowerManagerService.java:3785) 07-31 10:28:12.938 408 430 W Watchdog: - waiting to lock <0x08eacc86> (a java.lang.Object) 07-31 10:28:12.938 408 430 W Watchdog: at com.android.server.Watchdog$HandlerChecker.run(Watchdog.java:247) 07-31 10:28:12.939 408 430 W Watchdog: at android.os.Handler.handleCallback(Handler.java:938) 07-31 10:28:12.939 408 430 W Watchdog: at android.os.Handler.dispatchMessage(Handler.java:99) 07-31 10:28:12.939 408 430 W Watchdog: at android.os.Looper.loop(Looper.java:223) 07-31 10:28:12.939 408 430 W Watchdog: at android.os.HandlerThread.run(HandlerThread.java:67) 07-31 10:28:12.939 685 7715 E IpClient.eth0: ERROR disabling IPv6 failed: android.os.ServiceSpecificException: Remote I/O error (code 121) 07-31 10:28:12.939 408 430 W Watchdog: at com.android.server.ServiceThread.run(ServiceThread.java:44) 07-31 10:28:12.939 408 430 W Watchdog: *** GOODBYE! 07-31 10:28:12.939 408 430 I Process : Sending signal. PID: 408 SIG: 9 07-31 10:28:12.952 685 7715 E IpClient.eth0: ERROR error enabling IPv6 privacy extensions: android.os.ServiceSpecificException: Remote I/O error (code 121) 07-31 10:28:12.952 685 7715 E IpClient.eth0: ERROR onProvisioningFailure(): 5 07-31 10:28:29.650 2686 2686 W adbd : timeout expired while flushing socket, closing
最新发布
08-01
<think>我们正在分析两个不同但相关的系统问题:ANR(应用无响应)和Watchdog(系统监视狗)导致的系统进程卡死。用户的问题是:PowerManagerService卡死在monitor方法,系统进程被Watchdog杀死,是否会导致整个系统卡死?如何解决? 根据引用[1]和引用[2]提供的信息,Watchdog会监控系统关键线程(如android.fg, main, display, anim等)是否阻塞。当这些线程被阻塞超过一定时间(默认60秒),Watchdog会触发并杀死系统进程,导致系统重启或部分功能瘫痪。 下面分步骤分析: 1. **ANR和Watchdog的区别**: - **ANR**:针对单个应用程序,当主线程被阻塞超过5秒(用户输入)或10秒(BroadcastReceiver),系统弹出ANR对话框,但不会导致系统重启。 - **Watchdog**:针对系统核心进程(如system_server),如果关键线程被阻塞超过60秒,Watchdog会强制重启系统进程,可能导致整个系统卡死或重启。 2. **Watchdog日志分析(引用[1][2])**: - 日志显示多个线程被阻塞,包括`android.fg`(前台线程)、`main`(主线程)等。 - 阻塞点:`com.android.server.am.ActivityManagerService`(AMS)和`PowerManagerService`(PMS)等核心服务。 - 例如:`Blocked in monitor com.android.server.am.ActivityManagerService on foreground thread (android.fg)` 表示AMS的监视器(monitor)锁住了前台线程,导致其他线程无法执行。 3. **PowerManagerService卡死的原因**: - **死锁**:多个线程相互等待对方持有的锁,形成循环依赖。例如,线程A持有锁L1等待锁L2,线程B持有锁L2等待锁L1。 - **长时间阻塞操作**:在同步方法(synchronized)或锁保护区域内执行了耗时操作(如I/O、复杂计算)。 - **资源竞争**:高并发下锁竞争激烈,导致线程长时间等待。 4. **是否会导致整个系统卡死?** - **会**。因为PowerManagerService是系统核心服务,负责管理设备电源状态(如唤醒、休眠)。如果它卡死,会连锁导致依赖它的线程(如AMS、Display)也被阻塞,最终触发Watchdog重启系统。用户会观察到系统无响应、自动重启或部分功能(如屏幕点亮)失效。 5. **解决方案**: - **步骤1:定位死锁点** 分析Watchdog日志和系统traces(`/data/anr/traces.txt`或`/data/system/dropbox/`),找到阻塞的线程堆栈。例如: ``` "android.fg" tid=12 Blocked at com.android.server.power.PowerManagerService.acquireWakeLockInternal(PowerManagerService.java:1234) - waiting to lock <0x12345> (a com.android.server.power.PowerManagerService$WakeLock) at com.android.server.power.PowerManagerService.acquireWakeLock(PowerManagerService.java:1189) ... "ActivityManager" tid=15 Blocked at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:5678) - waiting to lock <0x67890> (a java.lang.Object) at ... at com.android.server.power.PowerManagerService.releaseWakeLockInternal(PowerManagerService.java:1300) - locked <0x12345> (a com.android.server.power.PowerManagerService$WakeLock) ``` 上述示例中: - `android.fg`线程等待锁`0x12345`(PowerManagerService内部的锁) - `ActivityManager`线程持有锁`0x12345`,但等待另一个锁`0x67890`(在AMS中),而AMS的锁可能被其他线程持有。 - **步骤2:修复死锁** - **避免嵌套锁**:减少同步范围,尤其不在锁内调用外部方法(可能持有其他锁)。 - **锁顺序**:统一多个锁的获取顺序(如先A后B),打破循环等待。 - **使用超时锁**:用`tryLock(timeout)`替代`synchronized`,超时后释放并重试或报错。 - **异步处理**:将耗时操作移出同步块,用Handler或异步任务执行。 - **步骤3:优化PowerManagerService** - 检查`PowerManagerService`中同步方法(如`acquireWakeLockInternal`)的耗时操作,移出同步块。 - 减少锁的粒度:用细粒度锁(如每个WakeLock单独锁)代替整个Service的大锁。 - **步骤4:系统级防护** - **Watchdog超时调整**:临时增加超时时间(不推荐,仅调试用)。 - **监控与告警**:在系统代码中添加日志,监控锁竞争情况。 6. **实例代码(修复死锁)**: 假设死锁发生在`PowerManagerService`和`ActivityManagerService`之间: 原代码(伪代码): ```java // PowerManagerService.java synchronized void releaseWakeLockInternal() { // ... 需要调用AMS的方法 mActivityManagerService.someMethod(); // 可能尝试获取AMS的锁 } // ActivityManagerService.java synchronized void someMethod() { // ... 需要调用PowerManagerService的方法 mPowerManagerService.acquireWakeLock(...); // 尝试获取PowerManagerService的锁 } ``` 修复:调整锁顺序,并避免在锁内调用外部服务。 ```java // 修改后:在AMS中调用PowerManagerService时,先释放自己的锁 void someMethod() { // 先完成本地同步块内的操作 synchronized(this) { // ... 快速操作 } // 再调用外部服务(此时已释放AMS锁) mPowerManagerService.acquireWakeLock(...); } ``` 7. **验证**: - 复现问题:使用压力测试(如Monkey测试)验证死锁是否修复。 - 监控日志:确保Watchdog不再触发。 总结:PowerManagerService卡死会通过Watchdog导致系统卡死或重启。解决核心是分析死锁链并打破循环等待。同时,优化锁的使用和减少同步块耗时是关键。 ### 相关问题 1. 如何获取和分析Android系统traces文件? 2. 在Android系统开发中,如何设计避免死锁? 3. Watchdog机制的工作原理是什么?如何调整其超时时间? 4. 如何模拟和测试系统死锁场景?</think>### Android ANR与Watchdog日志分析:系统卡死问题与解决方案 #### 一、问题本质分析 1. **ANR与Watchdog的区别**: - **ANR(应用无响应)**:当应用主线程阻塞超过阈值(通常5秒),系统弹出提示但**不会杀死进程**[^1]。 - **Watchdog(系统监视狗)**:监控系统核心服务(如`ActivityManagerService`, `PowerManagerService`)。若其线程阻塞超时(默认60秒),会**强制重启系统进程**[^2]。 2. **PowerManagerService卡死的危害**: ```mermaid graph LR A[PowerManagerService卡死] --> B[电源管理失效] B --> C[屏幕/唤醒功能异常] C --> D[依赖电源的服务阻塞] D --> E[多个系统线程连环阻塞] E --> F[Watchdog触发系统重启] ``` - 当`PowerManagerService`在`monitor`方法卡死时,会导致: - 系统无法响应电源键操作 - 屏幕常亮或无法唤醒 - 连锁阻塞AMS(ActivityManagerService)等关键服务[^2] - **最终结果**:Watchdog强制杀死系统进程,导致**整机卡死或自动重启**。 #### 二、根本原因定位 通过日志分析常见诱因: 1. **死锁问题**: - 多个线程循环等待资源(如`android.fg`与`ActivityManager`线程相互阻塞)[^1][^2] - 同步代码设计缺陷,例如: ```java // 错误示例:嵌套同步块导致死锁风险 synchronized(lockA) { synchronized(lockB) { // 若其他线程以相反顺序获取锁则死锁 // ... } } ``` 2. **资源耗尽**: - CPU负载过高(如日志中`65% TOTAL`负载) - 内存泄漏导致OOM(Out of Memory) 3. **硬件驱动故障**: - 电源管理驱动异常(如`mcu_battery`服务异常) - I/O阻塞(日志中`iowait`占比异常) #### 三、解决方案 ##### 阶段1:紧急恢复 1. **强制重启**: - 长按电源键10秒强制重启设备 - 通过ADB命令重启系统进程: ```bash adb shell su -c "pkill -l 9 system_server" ``` ##### 阶段2:问题修复 1. **死锁问题修复**: - 使用`tryLock()`替代同步块,设置超时机制: ```java if (lock.tryLock(100, TimeUnit.MILLISECONDS)) { try { /* 操作 */ } finally { lock.unlock(); } } ``` - 统一锁获取顺序,避免嵌套锁 2. **PowerManagerService优化**: ```java public void monitor() { // 添加超时检测 final long start = SystemClock.uptimeMillis(); while (condition) { if (SystemClock.uptimeMillis() - start > 5000) { Slog.w(TAG, "Monitor timeout!"); return; } SystemClock.sleep(100); } } ``` 3. **系统负载优化**: - 限制后台进程CPU使用: ```bash # 限制网络进程CPU占用 adb shell cpulimit -p 685 -l 30 ``` - 启用内存压缩: ```bash echo 1 > /sys/module/zram/parameters/max_comp_streams ``` ##### 阶段3:预防措施 1. **监控增强**: - 添加Watchdog心跳检测: ```java Watchdog.getInstance().addMonitor(new PowerManagerMonitor()); ``` - 定期生成系统快照: ```bash adb bugreport ``` 2. **硬件层防护**: - 更新电源管理驱动 - 添加硬件看门狗电路 #### 四、验证与测试 1. **压力测试命令**: ```bash # 模拟高负载场景 adb shell stress --cpu 8 --io 4 --vm 2 --timeout 300 ``` 2. **死锁检测工具**: ```bash adb shell dumpsys window | grep -i monitor adb shell cat /proc/locks ``` > **结论**:PowerManagerService卡死会通过Watchdog导致系统级卡死或重启。通过死锁修复、资源优化和监控增强可彻底解决。[^1][^2] ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值